<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">My thoughts on how to manage our history:</div><div class=""><br class=""></div><div class="">- For the initial transition we should really stay with linear history as that is what we are used to from the svn world!</div><div class=""><br class=""></div><div class="">As for the future directions:</div><div class="">- 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. 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), bisection also gets a lot harder with merges in the history as it is hard to decide which branch to follow.</div><div class="">- 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!</div><div class=""><br class=""></div><div class="">- Matthias</div><div class=""><br class=""></div><div><blockquote type="cite" class=""><div class="">On Jun 2, 2016, at 12:38 PM, Craig, Ben via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
<meta content="text/html; charset=utf-8" http-equiv="Content-Type" class="">
<div bgcolor="#FFFFFF" text="#000000" class="">
<div class="moz-cite-prefix">On 6/2/2016 1:48 PM, via llvm-dev
wrote:<br class="">
</div>
<blockquote cite="mid:nnga8j3mnq7.fsf@lnx-dag.us.cray.com" type="cite" class="">
<pre wrap="" class="">Mehdi Amini via llvm-dev <a class="moz-txt-link-rfc2396E" href="mailto:llvm-dev@lists.llvm.org"><llvm-dev@lists.llvm.org></a> writes:
</pre>
<blockquote type="cite" class="">
<pre wrap="" class="">Github has an automatic "squashed" mode for pull requests now, I
haven't tested in practice but it may help.
</pre>
</blockquote>
<pre wrap="" class="">IMHO squashed commits are a bad idea from a bisect perspective. One of
the great benefits of git is the easy of creating small,
logically-independent commits that can be bisected. Squashing
eliminates that advantage.
An automatic rebase of the branch and fast-forward merge would be a fine
way to maintain linear history. I have no idea how/if GitHub supports
that though.
-David</pre>
</blockquote>
Squashing or not depends a lot on personal workflow and the
automation that is in place. On a different project I maintained,
there was automation that would retrigger tests when a personal
branch on github was updated. This encouraged committers to submit
lots of tiny patches that didn't necessarily make sense in
isolation. You'd get intermediate commit messages like "fixed a
semi" or "asdfafshg". The overall branch and pull request would
make sense. There was also value to the individual in that they
could commit frequently, try out crazy stuff, and rewind if
necessary. The end result though was that you would have a branch
that would either ugly up the history a lot, or require a squash.<br class="">
<br class="">
Some people prefer to trigger those kinds of automation tasks with a
git commit --amend. While this keeps branch history clean, you lose
intermediate states, making it more difficult to rewind when your
in-progress work goes bad. It also makes life harder for anyone
that forks your branch, as now you are rewriting history.<br class="">
<br class="">
So my opinion on this is that you either need to deal with the evils
of --amend, or you need to have a squash somewhere in the process,
or you need to get everything right the first time. My preference
is for a squash in the middle.<br class="">
<br class="">
Note that this entire line of reasoning is assuming that we are
talking about small topic / bug fixing branches. If you have a
"big" branch, then that "big" branch needs to have a clean history
as well. I think that a regular, un-squashed merge is the best way
to handle "big" branches.<br class="">
<br class="">
<br class="">
--
<pre class="moz-signature" cols="72">Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
</pre>
</div>
_______________________________________________<br class="">LLVM Developers mailing list<br class=""><a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a><br class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev<br class=""></div></blockquote></div><br class=""></body></html>