On 6/4/07, Linus Torvalds <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 :)
> In *practice*, I suspect that once you get used to the git model, you'd
> actually end up with a hybrid scheme, where you might have a *smaller*
> core group with commit access to the central repository (in git, it
> wouldn't be "commit access", it would really be "ability to push", but
> that's a technical difference rather than anything conceptually huge), and
> members in that core group end up pulling from others.
This sounds like what we eventually came up with. I'm not sure how
soon we'll make a switch to a git repository, but when we do, this
seems to be the best model for the conversion in the short term, and
perhaps in the long term too.
> .. and that's exactly how you'd do it with git too. You wouldn't have a
> "commit trigger", but you'd have a "receive trigger", which triggers
> whenever somebody pushes to the central repository.
Yes, after I'd sent my email this morning I found you could do pushes
as well as pulls. That'll teach me to RTFM properly next time.
> - realize that the git model tends to encourage many small commits
> (because you *can* make commits without impacting others), so when you
> fix something, or add a new feature, with git, you can do it as many
> small steps, and then only "push" when it's ready.
This is what I personally was trying to advocate in our discussion -
but I'm not sure everyone quite understood it. Hopefully your
explanation will do a better job :)
> IOW, if you encourage people to do small step-wise changes, you
> probably don't even *want* a build for each commit, you really want a
> build for the case where "my feature is now ready, I'll push". So you'd
> effectively get one build not per commit, but per "publication point".
Absolutely.
> Linus
Thanks for your time (and everyone else who replied) - it's very much
appreciated!
Bryan