On 6/4/07, Linus Torvalds < [send email to
torvalds@xxxxxxxxxxxxxxxxxxxx via gmail]
torvalds@xxxxxxxxxxxxxxxxxxxx> 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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
