Advertising
- Unnamed
- Monday, June 4th, 2007 at 9:40:18am MDT
- 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
advertising
Update the Post
Either update this post and resubmit it with changes, or make a new post.
You may also comment on this post.
Please note that information posted here will expire by default in one month. If you do not want it to expire, please set the expiry time above. If it is set to expire, web search engines will not be allowed to index it prior to it expiring. Items that are not marked to expire will be indexable by search engines. Be careful with your passwords. All illegal activities will be reported and any information will be handed over to the authorities, so be good.
