[LLVMdev] git

[Chris Lattner]

On Jul 29, 2011, at 11:26 AM, David A. Greene wrote:
>> 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.
> 
> It is silly.  I see no reason to simply ignore the later patches unless
> patch 6 needs a substantial rework.

Again, I value reviewer time (which is scarce if you haven't noticed) more than patch submitter time.

If patch 6 needs rework, it can cause ripple effects through the rest of the patch series.  I believe that your recent tblgen changes are a perfect example of this.

>> Instead, what I should see are (for example) and be asked to review
>> them.
> 
> Oops, I think something got botched here.  I can't parse the above.  :)

Yeah, parse error for me too. :)

>> 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.
> 
> Thanks, that clarifies things.  So you don't so much demand individual
> cherry-picks to master as you demand that merges to master be smallish
> and incremental.  I think that is entirely reasonable.

Right.

> With my most recent patch, I submitted something I considered logically
> connected.  I was asked to rework it and break it up.  I did that and
> submitted the resulting patch stream for review.  No one seemed to
> complain about that so I wasn't grokking your dislike of that apporoach.
> Now I am much more clear about how to use this git thing with LLVM.  :)

Great, thanks.

-Chris