On Jul 22, 2011, at 3:45 PM, Bob Wilson wrote:> > On Jul 22, 2011, at 3:33 PM, fly language wrote: > >> >> After git, mainline will still be the most important branch for the *project*, >> but you will work with quite a few branches on parallel. >> >> >> Who's mainline? :) Be prepared to assign a super-merger, like Linus, to maintain the "mainline". >> >> The git workflow works really really great, but it does require getting rid of mainline thinking. It doesn't exist. > > I strongly disagree with this. Having a mainline, whether enforced by the VCS or not, is crucial to our incremental development philosophy. For example, we need small, incremental patches going into one mainline branch in order for our buildbots to usefully identify regressions. We also bisect performance regressions quite a lot, but if someone goes off and does a bunch of development on a branch and then lands it in mainline all at once, we'll be completely unable to pinpoint the source of any regressions from that branch.Bob is spot on here. The part I agree with in concept is: "I agree that changing from SVN to GIT could be beneficial". I specifically *do not* think that we should fundamentally change our development methodology. Mainline should exist, it should be where code reviews happen, and the existing policies around it should continue to exist. Release branches should be made from it every ~6 months, etc. I really do appreciate distributed VCS, but only as staging. Incremental development is crucial for the project and "take this git push with 100K of code" will never be acceptable. -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110722/de5db7d5/attachment.html>
Matthieu Moy <Matthieu.Moy at grenoble-inp.fr> writes:> With Git's best practice, you may have such history locally, but you > should not push it as it is. You usually rework your history (things > like "git rebase -i" are just great for that) to clean it up, and then > have it accepted by upstream. Ideally, you make sur the testsuite passes > for each commit before pushing. > > If you like incremental development, you're going to love DVCS.Let me report a recent experience here. Some of you may recall that not long ago I proposed a rather intrusive change to TableGen with the goal of making Inits unique. My original patch was large and I was asked to break it up. Initially, I was quite resistant. There was much wailing and gnashing of teeth. Not really because I thought it was the wrong thing to do, but because of the pain I forsaw in actually accomplishing the task. You may have also noted that as the review process went on, I got less and less resistant. That's not because I gave up. :) It's because I gained a lot of experience with git and things like rebase -i and add -i. It was *much* easier to respond to review feedback with git than with svn because git directly supports the kind of review iteration on patches that we want to see. It's designed to make that process less painful. I think this is another killer feature of git. -Dave
On Sat, Jul 23, 2011 at 01:34:40PM +0200, Matthieu Moy wrote:> Incremental development is probably promoted by DVCS far more than > others. Your comment seems to imply that only the tip of each push is > important. In the Git world, it usually isn't.Pushing a 100K patch is a 100K patch, whether it is done in one chunk or 100 smaller incrementell patches. Just because review for the former as a single chunk is a bit more complicated doesn't mean that reviewing the latter is attractive. Let's face it -- noone likes to review that much code in one go. There is also nothing stopping you from building smaller incrementell patches with other tools. It's been done before the invention of git after all. Joerg