[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