On Jul 23, 2011, at 4:34 AM, Matthieu Moy wrote:> Chris Lattner <clattner at apple.com> writes: > >> 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. > > 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. > > The flow promoted by Git is precisely to make sure each and every commit > passes the tests. So, the granularity of "incremental development" is > really the commit, not how often you merge.Again, to reiterate, I don't care. This model is based on the idea of some trusted maintainer doing code review of the branch and then pushing it to mainline as a huge batch when everything is happy and working. This is fundamentally in tension with the LLVM model and I have no desire for us to switch. -Chris> > "git bissect" is a good illustration of this. It does not only bissect > accross the mainline, but it does all along the DAG. For example, if you > bisect a regression between linux-2.6.38 and linux-2.6.39, you may well > end up with a guilty commit that was written long before linux-2.6.38, > but merged in the window between 2.6.38 and 2.6.39. > > In a world where only merges are important, it's acceptable to have a > history like > > merge feature A > +- start feature A > +- oops, typo > +- oops, forgot a svn add > +- continue feature A > +- oops, another fix in first commit > merge feature B > ... > > 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. > > -- > Matthieu Moy > http://www-verimag.imag.fr/~moy/
On Jul 28, 2011, at 2:16 PM, David A. Greene wrote:>>> The flow promoted by Git is precisely to make sure each and every commit >>> passes the tests. So, the granularity of "incremental development" is >>> really the commit, not how often you merge. >> This model is based on the idea of some trusted maintainer doing code >> review of the branch and then pushing it to mainline as a huge batch >> when everything is happy and working. This is fundamentally in >> tension with the LLVM model and I have no desire for us to switch. > > Ah. Here is where I think we have some miscommunication happening. > > Here's how I am thinking about things. Reviews should keep happening > the way they are.Agreed.> In fact, what we are doing now is exactly the same > work one would have to do to review a git branch, but that's immaterial.Disagreed. The point is that I should not see a stream of 20 decomposed patches from you. When I get to one that is "wrong" or needs changes (e.g. patch 6), then all the other patches after it get ignored. This is silly. Instead, what I should see are (for example) and be asked to review them. Here's a hypothetical example of what I want: Send in or directly commit 5 patches if they are "obvious" cleanups. These are patches that just move things around in obvious ways, fix formatting, whatever. Send in a patch 6 and wait for review of *just it* saying "this does something crazy, here is why, here is why it is the best thing to do". Someone will review it, and if there are any problems, it goes back to you for revision. It eventually goes in when it is good for the tree. After that patch is in, another stream of obvious patches are unblocked and go directly in. Patch 12 comes around, gets reviewed just like #6... etc. I *don't* want to see all 20 patches up front.> I think the disagreement (if we can call it that) is really over what > actually gets pushed to "mainline" which I assume would be defined as > "master" on llvm.org.No. The fundamental disagreement/misunderstanding here is that you are optimizing for an out-of-tree maintainer pushing "batches" of work upstream. This is not what I'm at all interesting in optimizing for, and if you're irritated about the turn-around time that it takes to get review, then you shouldn't be optimizing for this either. -Chris