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

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>

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>

"Craig, Ben via llvm-dev" <llvm-dev at lists.llvm.org> writes:
> 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.
There's a third option: run as many tests as you can locally before
making your branch public.  Get the history as clean as possible before
you push.  If server-side testing reveals problems, either add fixup
commits or rewrite history (or which squash is just a subset operation).

No matter what, once you push your branch and make it public, anyone
could pull it and then rewriting history gets trickier.  IME it's best
to avoid doing that as much as possible.

I'm not saying squashes or history rewrites should never be done.  I'm
just suggesting that perhaps we should try to limit it.

Again, IME people tend to over-use squash, either explicitly or
implicitly by creating giant commits.  This is particularly true with
people new to git because it's more like the SVN model where everything
you commit is immediately public.  It surprised me how hard it was to
get people to understand that a commit is not public until you push it.
People are generally fearful of doing local history rewrites to clean it
up because they've heard all kinds of "rebase is evil" advice
without
the proper context.

                          -David

Matthias Braun via llvm-dev <llvm-dev at lists.llvm.org> writes:
> - 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.
We often revert entire feature merges when problem arise.  It's much
easier to do in a merging workflow because you have a single commit to
revert.  In the end I don't really care which model LLVM uses.  I just
want to provide as much working knowledge as I can based on experience
doing exactly this kind of SVN->git transition.
> 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),
It's certainly true that merge commits make history harder to follow
with "git log."  I find "git log --oneline --graph
--decorate" to be
pretty useful.
> bisection also gets a lot harder with merges in the history as it is
> hard to decide which branch to follow.
I don't understand this statement at all.  git-bisect handles merges
just fine.  We use a heavily branching/merging model and we've never had
a problem bisecting.
> - 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!
I generally agree with this.  The main problem that arises is someone
needing to do a fixup commit on a branch that someone else has accessed.
Then it's a history rewrite for the other person and that gets ugly.  I
don't anticipate this kind of local branch sharing to happen freqently,
at least not among people who are uncomfortable with git.  git experts
will know what to do with the situation.

                               -David

> No matter what, once you push your branch and make it public, anyone
> could pull it and then rewriting history gets trickier.  IME it's best
> to avoid doing that as much as possible.
If we have automation that looks at public topic branches (possibly 
because of a github pull request), then people will start making 
branches public sooner rather than later.  That's when we start getting 
into fixup territory.

If we don't put any of that automation in place, and we only run tests 
post-commit, then yeah, I think that keeping changes private as long as 
possible is probably best.

-- 
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/20160603/ce7b8079/attachment.html>