[llvm-commits] [llvm] r142523 - in /llvm/trunk/lib/TableGen: TGParser.cpp TGParser.h

David A. Greene greened at obbligato.org
Thu Oct 20 11:30:10 PDT 2011


Eric Christopher <echristo at apple.com> writes:

>> As I understand it, people objected to a bunch of commits in a short
>> amount of time.  I will throttle that next time.
>
> Sort of. Basically you went away for a while and then dumped a huge
> amount of code in a short while on people, that's largely what my
> objection was in this case. Part of incremental changes is not just
> that the patches are small, but that you're trying to work on top of
> tree as opposed to doing code dumps no matter how small. It may sound
> like a fuzzy thing, and it is, but it's the difference between saying:
> "here's the next part of what i'm working on, what do you think?" and
> "here's everything that i've done for the last 3 months and I demand
> you look at it now because I'm blocked until you look at all of them!"

A couple of things.

1. I like to get a particular feature working first and get the history
   in order before committing.  That prevents some unneeded churn as the
   implementation process uncovers design changes that need to be made.
   To me this is a huge advantage to the git mirror.

2. In this case I was waiting for the 3.0 branch.  So changes pile up.
   I have another bunch of changes for another feature that were waiting
   for the branch.

Regardless of #2, #1 is a big advantage for me.  It is tough to ask
people to wait on their design and implementation while people review
(or, most commonly don't review) their previous changes.  I have no
problem submitting those changes a little more slowly.  But I can't wait
for days of pinging and non-responses before I can work.

                         -Dave



More information about the llvm-commits mailing list