The trouble with firmware [LWN.net]

The trouble with firmware

Posted Jan 6, 2011 3:40 UTC (Thu) by JohnLenz (subscriber, #42089)
Parent article: The trouble with firmware

It is not enough to just have the new firmware filenames in the HEAD of the Git repository, Oliva and Stallman would like to eliminate references to the original filenames (and the firmware files themselves) from the repository history. But they also would like to be able to pull from Linus Torvalds's mainline tree periodically.

If you do this, doesn't git recompute the sha1 hashes for the commit id for all future commits, since the sha1 of the parent is included in the current commit? So changing one entry in the history will ripple sha1 hash changes throughout the whole tree.

If so, this sounds like a bad idea. If you report a bug on linux-kernel and someone says "This is fixed in 4d5227500c8f ...", that sha1 hash won't be in your tree, the same commit will be referenced with some other hash. Also, if do a git bisect, you won't be able to report it because the hashes from your git bisect won't match with what you need to report on linux-kernel.

I suppose you could keep around a map between Linus's sha1 and your sha1 ids and remember to convert whenever you send email to linux-kernel.

(Log in to post comments)

The trouble with firmware

Posted Jan 6, 2011 17:19 UTC (Thu) by bronson (subscriber, #4806) [Link]

> changing one entry in the history will ripple sha1 hash changes throughout the whole tree.

This is absolutely true. VCS bridges like git-svn and git-hg store the meta information in each commit's comment. The git-filter-branch script could, as you say, add a "Original-Commit: CF22A1..." line.

Not sure it would be worth it though -- I can't imagine the number of people using the FSF's tree would ever be very high (witness Gnusense).

The FSF is has a decent point, but the way they're making it is simply bizarre. It seems like they're trying to appeal only to their most fanatical supporters and discouraging everybody else. If they took a more mellow, community-oriented, and sustainable approach, people might actually listen. As it is, I bet this effort will go the way of the GNU/Linux appendage: lots of discussion, fizzle, and forget.

I don't care about Linux-libre, but I *do* care about ability to "change the history"

Posted Jan 6, 2011 18:29 UTC (Thu) by khim (subscriber, #9252) [Link]

In theory it's nice to have immutable history. In practice it'll be needed to remove some files from your server... completely. For legal reason.

So while it find the hoopla about Linux-libre strange and unneeded I'd like to see the solution for the problem discussed. I'm not needed it till now and I hope to never see the need for it, but... better safe than sorry...

I don't care about Linux-libre, but I *do* care about ability to "change the history"

Posted Jan 6, 2011 22:07 UTC (Thu) by bronson (subscriber, #4806) [Link]

I erased some history a few months ago when a production password was accidentally committed to our repo. I totally agree that the need exists, but I'm not sure we need a new tool. git filter-branch worked perfectly.

Yes, master's SHA changed, but that's exactly what I would expect to happen! I'd hate for someone to be able to change my history without any hint whatsoever.

I do wish git handled rewritten remote branches better. When some people pulled, they ended up with a bizarre-looking merge, one branch of which I suppose had missing objects (I didn't look, just blew it away and checked out a fixed tracking branch). git should say, "hey dude, upstream has yanked the rug out. Maybe check your email for instructions?" and refuse to do anything until you've rebased things back to normal.

But, yes, the SHA should always change!