Re: Git Vs. Svn for a project which *must* distribute binaries too.
- From
Linus Torvalds <torvalds@linux-foundation.org>
- Date
- Jun 5, 2007, 00:21 UTC
- Message-ID
- <alpine.LFD.0.98.0706041715500.23741@woody.linux-foundation.org>
- In-Reply-To
- <Pine.LNX.4.64.0706041923580.22840@iabervon.org>
On Mon, 4 Jun 2007, Daniel Barkalow wrote:
Show 5 quoted lines
> > Actually, I've been playing with using git's data-distribution mechanism > to distribute generated binaries. You can do tags for arbitrary binary > content (not in a tree or commit), and, if you have some way of finding > the right tag name, you can fetch that and extract it.
Yes, I think git should be very nice for doing binary stuff like firmware images too, my only worry is literally about "mixing it in" with other stuff.
Putting lots of binary blobs into a git archive should work fine: but if you would then start tying them together (with a commit chain), it just means that even if you only really want _one_ of them, you end up getting them all, which sounds like a potential disaster.
On the other hand, if you actually want a way to really *archive* the dang things, that may well be what you actually want. In that case, having a separate branch that only contains the binary stuff might actually be what you want to do (and depending on the kind of binary data you have, the delta algorithm might even be good at finding common data sequences and compressing it).
Show 5 quoted lines
> I came up with this at my job when we were trying to decide what to do > with firmware images that we'd shipped, so that we'd be able to examine > them again even if we lose the compiler version we used at the time. We > needed an immutable data store with a mapping of tags to objects, and I > realized that we already had something with these exact characteristics.
Yeah, if you just tag individual blobs, git will keep track of them, but won't link them together, so you can easily just look up and fetch a single one from such an archive. Sounds sane enough.
Linus