[LLVMdev] git

David A. Greene greened at obbligato.org
Thu Jul 28 14:16:51 PDT 2011

Chris Lattner <clattner at apple.com> writes:

> On Jul 23, 2011, at 4:34 AM, Matthieu Moy 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.  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.
There are great tools in git for sending a patch stream to the mailing
list.  To me, there isn't a compelling reason to change the current
review system.

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.  Chris wants the commits to happen in sequence, in
exactly the same order as patches sent to the review list.  It is not
very difficult to do this in git.  It's slightly more involved, but not
overly burdensome.

Others (like me) have argued that once patches have been reviewed on a
branch, merging the branch directly to master is not functionally
different than a stream of commits.  It is semantically different in the
way history gets presented on master, which is where I think the root of
the disagreement lies.  But either way, git bisect, etc. should be able
to ferret out any problems.

I'm not going to push hard against a "cherry-pick every commit to merge"
approach if it means we can move to git.  The benefits of a switch to
git far outweigh any downsides of the slightly increased merge work
relative to a "pure merge" approach.  That said, down the road after we
get some experience with git, I would hope we could open a discussion
about merge policy.  But not after quite some time.


More information about the llvm-dev mailing list