[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