From: Daniel Barkalow <barkalow@iabervon.org>
To: Bryan Childs <godeater@gmail.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>, git@vger.kernel.org
Subject: Re: Git Vs. Svn for a project which *must* distribute binaries too.
Date: Mon, 4 Jun 2007 19:48:54 -0400 (EDT) [thread overview]
Message-ID: <Pine.LNX.4.64.0706041923580.22840@iabervon.org> (raw)
In-Reply-To: <5971b1ba0706040838nc9ea7c7h54a57d4235d53bcf@mail.gmail.com>
On Mon, 4 Jun 2007, Bryan Childs wrote:
> On 6/4/07, Linus Torvalds < [send email to
> torvalds@linux-foundation.org via gmail]
> torvalds@linux-foundation.org> wrote:
> > So I *hope* that you want to just have automated build machinery that
> > builds the binaries to a *separate* location? You could use git to archive
> > them, and you can obviously (and easily) name the resulting binary blobs
> > by the versions in the source tree, but I'm just saying that trying to
> > track the binaries from within the same git repository as the source code
> > is less than optimal.
>
> Oh lord no - I never meant to imply that we'd be checking those
> binaries in, I just meant to hi-light that we need a central
> repository to build those binaries from - otherwise we'd end up with a
> selection of binaries for our users to download which contain a bunch
> of different features if they were built from a combination of
> repositories. I know you think everyone else is a moron, but we're not
> quite dumb enough to think maintaining binaries in a repository is a
> good idea :)
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.
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.
-Daniel
*This .sig left intentionally blank*
next prev parent reply other threads:[~2007-06-04 23:49 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 [this message]
2007-06-05 0:21 ` Linus Torvalds
2007-06-05 1:42 ` david
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.0706041923580.22840@iabervon.org \
--to=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).