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

[Matthias Braun via llvm-dev]

My thoughts on how to manage our history:

- For the initial transition we should really stay with linear history as that is what we are used to from the svn world!

As for the future directions:
- 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.
- 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!

- Matthias

> On Jun 2, 2016, at 12:38 PM, Craig, Ben via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> On 6/2/2016 1:48 PM, via llvm-dev wrote:
>> Mehdi Amini via llvm-dev <llvm-dev at lists.llvm.org> <mailto: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
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160602/799cd93f/attachment.html>