[llvm-dev] [cfe-dev] [lldb-dev] GitHub anyone?

David A. Greene via llvm-dev llvm-dev at lists.llvm.org
Thu Jun 2 19:47:30 PDT 2016

Matthias Braun via llvm-dev <llvm-dev at lists.llvm.org> writes:

> - Even in the long term I would vote to stay with linear history, I
> see little benefits in having "correct" origin information of a commit
> that the merging model provides.

We often revert entire feature merges when problem arise.  It's much
easier to do in a merging workflow because you have a single commit to
revert.  In the end I don't really care which model LLVM uses.  I just
want to provide as much working knowledge as I can based on experience
doing exactly this kind of SVN->git transition.

> On the other hand I find merge commits in the history unfriendly to
> readers (esp. the merges themselfes where you suddenly see conflicts
> of multiple commits getting resolved),

It's certainly true that merge commits make history harder to follow
with "git log."  I find "git log --oneline --graph --decorate" to be
pretty useful.

> bisection also gets a lot harder with merges in the history as it is
> hard to decide which branch to follow.

I don't understand this statement at all.  git-bisect handles merges
just fine.  We use a heavily branching/merging model and we've never had
a problem bisecting.

> - As for squashing: I don't see why people would enforce that on the
> server. Often developers went through the trouble of forming a nice
> series of independent patches that helps understanding the changes. To
> people just appending fixup commits like mentioned below I'd strongly
> advice them to learn about "git rebase -i" so they can squash on their
> local checkout as necessary before committing to the server!

I generally agree with this.  The main problem that arises is someone
needing to do a fixup commit on a branch that someone else has accessed.
Then it's a history rewrite for the other person and that gets ugly.  I
don't anticipate this kind of local branch sharing to happen freqently,
at least not among people who are uncomfortable with git.  git experts
will know what to do with the situation.


More information about the llvm-dev mailing list