<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 6/2/2016 1:48 PM, via llvm-dev
wrote:<br>
</div>
<blockquote cite="mid:nnga8j3mnq7.fsf@lnx-dag.us.cray.com"
type="cite">
<pre wrap="">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">
<pre wrap="">
Github has an automatic "squashed" mode for pull requests now, I
haven't tested in practice but it may help.
</pre>
</blockquote>
<pre wrap="">
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>
<br>
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>
<br>
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>
<br>
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>
<br>
<br>
--
<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>
</body>
</html>