Part of Slepp's ProjectsPastebinTURLImagebinFilebin
Feedback -- English French German Japanese
Create Upload Newest Tools Donate


Monday, June 4th, 2007 at 3:40:18pm UTC 

  1. On 6/4/07, Linus Torvalds <[email protected]> wrote:
  2. > So I *hope* that you want to just have automated build machinery that
  3. > builds the binaries to a *separate* location? You could use git to archive
  4. > them, and you can obviously (and easily) name the resulting binary blobs
  5. > by the versions in the source tree, but I'm just saying that trying to
  6. > track the binaries from within the same git repository as the source code
  7. > is less than optimal.
  9. Oh lord no - I never meant to imply that we'd be checking those
  10. binaries in, I just meant to hi-light that we need a central
  11. repository to build those binaries from - otherwise we'd end up with a
  12. selection of binaries for our users to download which contain a bunch
  13. of different features if they were built from a combination of
  14. repositories. I know you think everyone else is a moron, but we're not
  15. quite dumb enough to think maintaining binaries in a repository is a
  16. good idea :)
  19. > In *practice*, I suspect that once you get used to the git model, you'd
  20. > actually end up with a hybrid scheme, where you might have a *smaller*
  21. > core group with commit access to the central repository (in git, it
  22. > wouldn't be "commit access", it would really be "ability to push", but
  23. > that's a technical difference rather than anything conceptually huge), and
  24. > members in that core group end up pulling from others.
  26. This sounds like what we eventually came up with. I'm not sure how
  27. soon we'll make a switch to a git repository, but when we do, this
  28. seems to be the best model for the conversion in the short term, and
  29. perhaps in the long term too.
  32. > .. and that's exactly how you'd do it with git too. You wouldn't have a
  33. > "commit trigger", but you'd have a "receive trigger", which triggers
  34. > whenever somebody pushes to the central repository.
  36. Yes, after I'd sent my email this morning I found you could do pushes
  37. as well as pulls. That'll teach me to RTFM properly next time.
  39. >  - realize that the git model tends to encourage many small commits
  40. >    (because you *can* make commits without impacting others), so when you
  41. >    fix something, or add a new feature, with git, you can do it as many
  42. >    small steps, and then only "push" when it's ready.
  44. This is what I personally was trying to advocate in our discussion -
  45. but I'm not sure everyone quite understood it. Hopefully your
  46. explanation will do a better job :)
  48. >    IOW, if you encourage people to do small step-wise changes, you
  49. >    probably don't even *want* a build for each commit, you really want a
  50. >    build for the case where "my feature is now ready, I'll push". So you'd
  51. >    effectively get one build not per commit, but per "publication point".
  53. Absolutely.
  55. >                 Linus
  57. Thanks for your time (and everyone else who replied) - it's very much
  58. appreciated!
  60. Bryan


Update the Post

Either update this post and resubmit it with changes, or make a new post.

You may also comment on this post.

update paste below
details of the post (optional)

Note: Only the paste content is required, though the following information can be useful to others.

Save name / title?

(space separated, optional)

Please note that information posted here will not expire by default. 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.

comments powered by Disqus