git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: david@lang.hm
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Daniel Barkalow <barkalow@iabervon.org>,
	Bryan Childs <godeater@gmail.com>,
	git@vger.kernel.org
Subject: Re: Git Vs. Svn for a project which *must* distribute binaries too.
Date: Mon, 4 Jun 2007 18:42:02 -0700 (PDT)	[thread overview]
Message-ID: <Pine.LNX.4.64.0706041841010.6705@asgard.lang.hm> (raw)
In-Reply-To: <alpine.LFD.0.98.0706041715500.23741@woody.linux-foundation.org>

On Mon, 4 Jun 2007, Linus Torvalds wrote:

> On Mon, 4 Jun 2007, Daniel Barkalow wrote:
>>
>> 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.

if you put the binaries in a seperate repository and do shallow clones to 
avoid getting all the old stuff wouldn't that work well?

David Lang

> 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).
>
>> 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
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

  reply	other threads:[~2007-06-05  1:41 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-04 11:48 Git Vs. Svn for a project which *must* distribute binaries too Bryan Childs
2007-06-04 11:56 ` Julian Phillips
2007-06-04 13:18 ` Theodore Tso
2007-06-04 14:58 ` Johannes Schindelin
2007-06-04 15:20 ` Linus Torvalds
2007-06-04 15:38   ` Bryan Childs
2007-06-04 16:23     ` Linus Torvalds
2007-06-04 17:57       ` Thomas Glanzmann
2007-06-04 20:45         ` Linus Torvalds
2007-06-04 21:21           ` Olivier Galibert
2007-06-04 21:33             ` Linus Torvalds
2007-06-04 22:30               ` Joel Becker
2007-06-05 11:19                 ` Theodore Tso
2007-06-05  2:56             ` Johannes Schindelin
2007-06-04 22:29     ` Martin Langhoff
2007-06-04 23:48     ` Daniel Barkalow
2007-06-05  0:21       ` Linus Torvalds
2007-06-05  1:42         ` david [this message]
2007-06-05  3:58           ` Linus Torvalds
2007-06-04 23:46 ` Jakub Narebski
2007-06-06 22:34   ` Jakub Narebski
  -- strict thread matches above, loose matches on Subject: below --
2007-06-07  4:36 linux
2007-06-07  7:57 ` Bryan Childs
2007-06-07 16:51   ` linux
2007-06-08 20:41     ` Jan Hudec

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.64.0706041841010.6705@asgard.lang.hm \
    --to=david@lang.hm \
    --cc=barkalow@iabervon.org \
    --cc=git@vger.kernel.org \
    --cc=godeater@gmail.com \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).