[LLVMdev] git

OvermindDL1 overminddl1 at gmail.com
Mon Aug 1 21:49:30 PDT 2011


On Fri, Jul 29, 2011 at 1:06 PM, Chris Lattner <clattner at apple.com> wrote:
> 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.

Just as a pure external viewer, and as a user of both git (past year)
and svn (long term, though admittedly the svn part is forced upon me
due to a server requirement that I itch to get rid of in the coming
months), all of the talk here of the reviewing process and all such
seems to work well on github/gitorious.  The code reviewing there can
be done by more people, lets you put comments about changed on even
individual lines of a patch if you want, flows a *LOT* better then
just an email-flood (as I experienced for the short time I was on the
llvm commit list).  I prefer github, but due to their
commercializations I am not able to run a copy locally (at work, not
always a good Internet connection but the multi-gigabit network
handles everything internally very well), so I set up Gitorious (which
was a hell of pain I must say, ruby sucks...) and it works very well.
We have been using something akin to the git flow (how have I not
heard of that before?!  Thanks!) and it works wonderfully.  Code
reviews happen for the pulls/pushs of other branches in gitorious all
with the nice interface and wonderful history tracking.

So I am just curious, how is the email flood better in comparison?



More information about the llvm-dev mailing list