[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.

                               -David


More information about the llvm-dev mailing list