[llvm-dev] [cfe-dev] [lldb-dev] GitHub anyone?

[Craig, Ben via llvm-dev]

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.
>
>                             -David
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...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160602/f5d13f82/attachment.html>