[llvm-dev] [cfe-dev] [lldb-dev] GitHub anyone?
Craig, Ben via llvm-dev
llvm-dev at lists.llvm.org
Thu Jun 2 12:38:51 PDT 2016
On 6/2/2016 1:48 PM, via llvm-dev wrote:
> Mehdi Amini via llvm-dev <llvm-dev at lists.llvm.org> writes:
>> Github has an automatic "squashed" mode for pull requests now, I
>> haven't tested in practice but it may help.
> 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.
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.
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.
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.
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.
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev