Amending merge commits?

Amending merge commits?

[Besen, David]

[-- Attachment #1: Type: text/plain, Size: 357 bytes --]


Hi folks,

I think one of my coworkers has stumbled on a git bug -- if you amend a merge commit, and then pull, your amends are lost.

Is this expected behavior?

I've reproduced the problem in a script (attached).  I ran it against a couple of versions of git (1.7.1, 1.7.9, 1.8.4, 2.0.0) and in each case it seemed to lose the amend.

- Dave


[-- Attachment #2: amend-merge.sh --]
[-- Type: application/octet-stream, Size: 1061 bytes --]

#!/bin/bash

set -ex

if [ -z "$GIT" ]; then GIT=git; fi
GIT_MERGE_AUTOEDIT=no

# Clean up from the last run
rm -rf repo.git repo repo2 || :

# Set up a bare "remote" repo
$GIT init --bare repo.git

# Check out the "remote" repo
$GIT clone repo.git repo

# Add a commit
cd repo
echo "file" > file.txt
$GIT add file.txt
$GIT commit -m "Add file.txt"
$GIT push origin master

# Make a branch
$GIT checkout -b mybranch

# Add a commit on the branch
echo "mybranch" >> file.txt
$GIT add .
$GIT commit -m "Add 'mybranch' line"

# Go back to master
$GIT checkout master

# Merge in mybranch to create a merge commit
$GIT merge --no-ff mybranch

# Push that back
$GIT push

# Amend the merge commit
echo "amended" >> file.txt
$GIT add .
$GIT commit -C HEAD --amend

cd ..

# Make a second checkout
$GIT clone repo.git repo2
cd repo2

# Add some unrelated changes to be pulled
echo "repo2" > file2.txt
$GIT add .
$GIT commit -m "Add file2"
$GIT push

cd ..
cd repo

# Pull
$GIT pull --rebase

# Now, we expect the text "amended" to be in file.txt
grep amended file.txt

Re: Amending merge commits?

[David Besen]

Besen, David <david.besen <at> hp.com> writes:

> 
> 
> Hi folks,
> 
> I think one of my coworkers has stumbled on a git bug -- if you amend a 
merge commit, and then pull, your amends
> are lost.
> 
> Is this expected behavior?
> 
> I've reproduced the problem in a script (attached).  I ran it against a 
couple of versions of git (1.7.1,
> 1.7.9, 1.8.4, 2.0.0) and in each case it seemed to lose the amend.
> 
> - Dave
> 
> 
> Attachment (amend-merge.sh): application/octet-stream, 1061 bytes


Whoops, accidentally encoded the script, here it is inline:

#!/bin/bash

set -ex

if [ -z "$GIT" ]; then GIT=git; fi
GIT_MERGE_AUTOEDIT=no

# Clean up from the last run
rm -rf repo.git repo repo2 || :

# Set up a bare "remote" repo
$GIT init --bare repo.git

# Check out the "remote" repo
$GIT clone repo.git repo

# Add a commit
cd repo
echo "file" > file.txt
$GIT add file.txt
$GIT commit -m "Add file.txt"
$GIT push origin master

# Make a branch
$GIT checkout -b mybranch

# Add a commit on the branch
echo "mybranch" >> file.txt
$GIT add .
$GIT commit -m "Add 'mybranch' line"

# Go back to master
$GIT checkout master

# Merge in mybranch to create a merge commit
$GIT merge --no-ff mybranch

# Push that back
$GIT push

# Amend the merge commit
echo "amended" >> file.txt
$GIT add .
$GIT commit -C HEAD --amend

cd ..

# Make a second checkout
$GIT clone repo.git repo2
cd repo2

# Add some unrelated changes to be pulled
echo "repo2" > file2.txt
$GIT add .
$GIT commit -m "Add file2"
$GIT push

cd ..
cd repo

# Pull
$GIT pull --rebase

# Now, we expect the text "amended" to be in file.txt
grep amended file.txt

Re: Amending merge commits?

[Jonathan Nieder]

Besen, David wrote:

> I think one of my coworkers has stumbled on a git bug -- if you
> amend a merge commit, and then pull, your amends are lost.

This is how pull --rebase works.  It turns your single-parent commits
into a sequence of patches on top of upstream and completely ignores
your merge commits.

There is a --rebase=preserve option that makes a halfhearted attempt
to preserve your merges --- perhaps that would help?  The
git-rebase(1) documentation has more details.

In an ideal world, I think pull --rebase would do the following:

 1. Do the same thing it does today
 2. Behind the scenes, *also* try a 'pull --merge' but don't save
    the result.
 3. Compare the results.  If they differ, show a diff and explain
    to the user what happened.

I may be the only one that wants that, though.

Hope that helps,
Jonathan

RE: Amending merge commits?

[Besen, David]

Ah thanks, I'll RTFM better in the future.

- Dave

-----Original Message-----
From: Jonathan Nieder [mailto:jrnieder@gmail.com] 
Sent: Friday, July 25, 2014 4:19 PM
To: Besen, David
Cc: git@vger.kernel.org
Subject: Re: Amending merge commits?

Besen, David wrote:

> I think one of my coworkers has stumbled on a git bug -- if you
> amend a merge commit, and then pull, your amends are lost.

This is how pull --rebase works.  It turns your single-parent commits
into a sequence of patches on top of upstream and completely ignores
your merge commits.

There is a --rebase=preserve option that makes a halfhearted attempt
to preserve your merges --- perhaps that would help?  The
git-rebase(1) documentation has more details.

In an ideal world, I think pull --rebase would do the following:

 1. Do the same thing it does today
 2. Behind the scenes, *also* try a 'pull --merge' but don't save
    the result.
 3. Compare the results.  If they differ, show a diff and explain
    to the user what happened.

I may be the only one that wants that, though.

Hope that helps,
Jonathan

Re: Amending merge commits?

[Jonathan Nieder]

David Besen wrote:
> Jonathan Nieder wrote:

>> This is how pull --rebase works.  It turns your single-parent commits
>> into a sequence of patches on top of upstream and completely ignores
>> your merge commits.
>>
>> There is a --rebase=preserve option that makes a halfhearted attempt
>> to preserve your merges --- perhaps that would help?  The
>> git-rebase(1) documentation has more details.
>
> Ah thanks, I'll RTFM better in the future.

No, not a problem.  It's very useful to see examples of where git's
behavior was counterintuitive and the documentation was more obscure
than it could have been.

I should also emphasize the "halfhearted" above.  There's a lot of
room for improvement in rebase --preserve-merges's handling of "evil"
and otherwise amended merges.

Thanks again,
Jonathan

Re: Amending merge commits?

[Sergei Organov]

Jonathan Nieder <jrnieder@gmail.com> writes:

> David Besen wrote:
>> Jonathan Nieder wrote:
>
>>> This is how pull --rebase works.  It turns your single-parent commits
>>> into a sequence of patches on top of upstream and completely ignores
>>> your merge commits.
>>>
>>> There is a --rebase=preserve option that makes a halfhearted attempt
>>> to preserve your merges --- perhaps that would help?  The
>>> git-rebase(1) documentation has more details.
>>
>> Ah thanks, I'll RTFM better in the future.
>
> No, not a problem.  It's very useful to see examples of where git's
> behavior was counterintuitive and the documentation was more obscure
> than it could have been.

Should documentaion warn that "git pull --rebase=true" (and
pull.merge=true configuration) could be harmful, and that
--rebase=preserve (and pull.merge=preserve) should better be used
instead?

Is there any scenario at all where pull --rebase=true wins over
preserve?

-- 
Sergey.

Re: Amending merge commits?

[Jonathan Nieder]

Sergei Organov wrote:

> Is there any scenario at all where pull --rebase=true wins over
> preserve?

Basically always in my book. ;-)

When people turn on 'pull --rebase', they are asking for a clean,
simplified history where their changes are small discrete patches in a
clump on top of upstream.

When someone has made a merge by mistake (with 'git pull' before
remembering to do an autosetuprebase, or with 'git merge' instead of
cherry-picking some patches they needed), the current --rebase=true
behavior can be a good way of cleaning up.

That said, in some specific workflows, --rebase=preserve may work
better than --rebase=true.  My hunch is that even those workflows are
not currently handled well with --rebase=preserve, alas.

A clearer explanation of --rebase (maybe with sub-headings for each
choice *true*, *false*, and *preserve*?) sounds useful.  An
illustration in the EXAMPLES section of git-pull(1) of the difference
between these three modes and when to use them would be even more
helpful.

Thanks,
Jonathan

Re: Amending merge commits?

[Sergei Organov]

Jonathan Nieder <jrnieder@gmail.com> writes:

> Sergei Organov wrote:
>
>> Is there any scenario at all where pull --rebase=true wins over
>> preserve?
>
> Basically always in my book. ;-)
>
> When people turn on 'pull --rebase', they are asking for a clean,
> simplified history where their changes are small discrete patches in a
> clump on top of upstream.

I think they rather ask for avoiding tons of meaningless automatic
merges resulting from periodic pulling from upstream.

Those subset of the above who only do small discrete patches don't do
merges to their tracking branches, except by mistake, right? If so,
'pull --rebase=preserve' makes no difference compared to --rebase=true
to their normal workflow. Moreover,if someone merges something to his
tracking branch by mistake, how is it different from making merge to any
other branch by mistake? Just fix the mistake by resetting to previous
state.

On the other hand, if someone decides to merge something else to his
tracking branch by purpose, both --rebase=preserve and --rebase=false
perform as expected, while --rebase=true may easily lead to huge
surprise. Please refer also to this thread for one such case:

http://www.mail-archive.com/git%40vger.kernel.org/msg55605.html

> When someone has made a merge by mistake (with 'git pull' before
> remembering to do an autosetuprebase, or with 'git merge' instead of
> cherry-picking some patches they needed), the current --rebase=true
> behavior can be a good way of cleaning up.

Once again, in case of mistake they are free to use --rebase=true, and
even then using 'git rebase' directly is probably cleaner. That said, I
don't argue --rebase=true could be sometimes useful. It's just that I
think --rebase=preserve is safer, so it should be a good idea to suggest
to use it (in favor of --rebase=true) in general.

> That said, in some specific workflows, --rebase=preserve may work
> better than --rebase=true.

It does indeed, and I don't think my aforementioned workflow is too
specific.

> My hunch is that even those workflows are not currently handled well
> with --rebase=preserve, alas.

--rebase=preserve works fine for the aforementioned workflow. At least
simple tests I performed so far ran fine. I'd like to learn though which
nasty drawbacks --rebase=preserve has for tracking branches compared to
--rebase=true, if any.

> A clearer explanation of --rebase (maybe with sub-headings for each
> choice *true*, *false*, and *preserve*?) sounds useful.  An
> illustration in the EXAMPLES section of git-pull(1) of the difference
> between these three modes and when to use them would be even more
> helpful.

That would be an improvement anyway, indeed.

-- 
Sergey.

Re: Amending merge commits?

[Sergei Organov]

Nico Williams <nico@cryptonector.com> writes:

> On Wed, Jul 30, 2014 at 3:42 AM, Sergei Organov <osv@javad.com> wrote:
>> Nico Williams <nico@cryptonector.com> writes:
>>> Local merge commits mean that you either didn't rebase to keep all
>>> your local commits on top of the upstream, or that you have multiple
>>> upstreams (the example exception I gave).
>>
>> I rather have multiple (release) branches on single upstream, say, v2.3
>> and v2.4. When something needs to be fixed in 2.3, it's fixed there and
>> pushed upstream, then, on 2.4, the 2.3 is merged to it, and result is
>> pushed upstream. When I do this merge, I need to push the merge
>
> Hmm, why not cherry-pick the fix?  That's how every project I know
> that ports fixes across release branches does it.

Cherry-pick? Why bother? What problem do we solve, having no merges
whatsoever? Why? GIT is so good at merges!

My impression is that people mostly rather do topic branches, and merge
them wherever they need the fixes, no?

>> upstream, and this won't work reliably when --rebase=true is acitve
>> (through pull.merge=rebase). If nothing changes upstream, I can simply
>> push this, and the merge is correctly preserved. However, if somebody
>> makes any changes upstream while I perform the merge, I'll need to pull
>> before pushing, and this immediately flattens-out my merge, that is
>> absolutely not what is needed here. Or I can simply pull before push,
>> just in case, and this flattens history even when there are no any
>> changes upstream!
>
> Does this change if you give your merge commits an different commit
> message?

Different from what? I'm almost sure commit message has nothing to do
with it. Please refer to this explanation to see for yourself how git
behaves when rebasing:

http://www.mail-archive.com/git%40vger.kernel.org/msg55605.html

>
>>> Conversely, if you always rebase your local commits on top of the
>>> upstream then you won't have merge commits to worry about.
>>
>> Wrong. I do alwys rebase my local commits on top of upstream, but I
>> still do have my own merge commits to worry about, as explained above.
>
> If you cherry-pick the cross-release-branch commits you'll not have a
> merge commit to worry about.

I fail to see why do you consider merge commits to be an evil, really. I
didn't think about cherry-picking carefully, but I don't feel
cherry-picking is the best tool for the job here. I suspect random
cherry-picking would create a mess, sooner or later.

-- 
Sergey.

Re: Amending merge commits?

[Nico Williams]

On Wed, Jul 30, 2014 at 3:42 AM, Sergei Organov <osv@javad.com> wrote:
> Nico Williams <nico@cryptonector.com> writes:
>> Local merge commits mean that you either didn't rebase to keep all
>> your local commits on top of the upstream, or that you have multiple
>> upstreams (the example exception I gave).
>
> I rather have multiple (release) branches on single upstream, say, v2.3
> and v2.4. When something needs to be fixed in 2.3, it's fixed there and
> pushed upstream, then, on 2.4, the 2.3 is merged to it, and result is
> pushed upstream. When I do this merge, I need to push the merge

Hmm, why not cherry-pick the fix?  That's how every project I know
that ports fixes across release branches does it.

> upstream, and this won't work reliably when --rebase=true is acitve
> (through pull.merge=rebase). If nothing changes upstream, I can simply
> push this, and the merge is correctly preserved. However, if somebody
> makes any changes upstream while I perform the merge, I'll need to pull
> before pushing, and this immediately flattens-out my merge, that is
> absolutely not what is needed here. Or I can simply pull before push,
> just in case, and this flattens history even when there are no any
> changes upstream!

Does this change if you give your merge commits an different commit message?

>> Conversely, if you always rebase your local commits on top of the
>> upstream then you won't have merge commits to worry about.
>
> Wrong. I do alwys rebase my local commits on top of upstream, but I
> still do have my own merge commits to worry about, as explained above.

If you cherry-pick the cross-release-branch commits you'll not have a
merge commit to worry about.

Nico
--

Re: Amending merge commits?

[Sergei Organov]

Nico Williams <nico@cryptonector.com> writes:

> On Tue, Jul 29, 2014 at 4:58 AM, Sergei Organov <osv@javad.com> wrote:
>> Nico Williams <nico@cryptonector.com> writes:
>>> That exception aside, keeping all local commits "on top" by always
>>> rebasing them onto the upstream is extremely useful: a) in simplifying
>>> conflict resolution, b) making it easy to identify as-yet-unintegrated
>>> local commits, c) making it easy to contribute local commits.
>>
>> But 'pull --rebase=preserve' does rebase local commits onto the
>> upstream, and result is exactly the same as 'pull --rebase=true', unless
>> you have some of your own merges to be rebased. That's where the
>> difference between these two options appears. It's --rebase=false that
>> performs merges rather than rebase.
>
> Local merge commits mean that you either didn't rebase to keep all
> your local commits on top of the upstream, or that you have multiple
> upstreams (the example exception I gave).

I rather have multiple (release) branches on single upstream, say, v2.3
and v2.4. When something needs to be fixed in 2.3, it's fixed there and
pushed upstream, then, on 2.4, the 2.3 is merged to it, and result is
pushed upstream. When I do this merge, I need to push the merge
upstream, and this won't work reliably when --rebase=true is acitve
(through pull.merge=rebase). If nothing changes upstream, I can simply
push this, and the merge is correctly preserved. However, if somebody
makes any changes upstream while I perform the merge, I'll need to pull
before pushing, and this immediately flattens-out my merge, that is
absolutely not what is needed here. Or I can simply pull before push,
just in case, and this flattens history even when there are no any
changes upstream!

Once again, nobody yet gave any clue of when/why pull.merge=preserve
configuration is inferior to pull.merge=rebase, as for all the scenario
you seem to care about they bring the same result.

> Conversely, if you always rebase your local commits on top of the
> upstream then you won't have merge commits to worry about.

Wrong. I do alwys rebase my local commits on top of upstream, but I
still do have my own merge commits to worry about, as explained above.

-- 
Sergey.

Re: Amending merge commits?

[Nico Williams]

On Tue, Jul 29, 2014 at 4:38 PM, Philip Oakley <philipoakley@iee.org> wrote:
> From: "Nico Williams" <nico@cryptonector.com>
>> That workflow works just fine with git.
>
> I'm not saying that it isn't a good technique and can work well. Rather I'm
> saying we should be tolerant of the rules and techniques of others who do
> [...]

Sure.  I was just giving advice as to how to avoid any problems at
pull time w.r.t. local merge commits.

Better merge commit handling at pull time might be great (I'd not
know; I avoid local merge commits!), but I would still strongly
recommend keeping all local commits on top because otherwise you lose
local history.  Even if you use -m to set a better commit message, you
might prefer to have kept the original N local -now rebased- commits
around so you can tell what each discrete change was, even if you'll
eventually squash them (you might not squash them all into one).

>>  It worked really well at Sun
>> (with thousands of engineers working on Solaris alone).  And it should
>> work well for anyone who doesn't have two or more forked upstreams to
>> follow.
>
> I'm just cautious of an accidental one size fits all approach, so the
> ability to rebase lines of development which contain merge commits should be
> possible (with an appropriate and documented option) without hidden traps.

Thus far the only case I've seen where this approach doesn't work _at
all_ is the case where you have multiple forked upstreams.  The only
other case where it doesn't work is a social problem: rebase allergy.
For the repos I maintain I insist on contributed commits applying as
fast forward merges, or I'll rebase them myself if need be.

Nico
--

Re: Amending merge commits?

[Philip Oakley]

From: "Nico Williams" <nico@cryptonector.com>
> On Tue, Jul 29, 2014 at 2:29 PM, Philip Oakley <philipoakley@iee.org> 
> wrote:
>> From: "Nico Williams" <nico@cryptonector.com>
>>> Local merge commits mean that you either didn't rebase to keep all
>>> your local commits on top of the upstream, or that you have multiple
>>> upstreams (the example exception I gave).
>>>
>>> Conversely, if you always rebase your local commits on top of the
>>> upstream then you won't have merge commits to worry about.
>>>
>> Whilst it may not be "the Git Way", I'd expect that in many less well
>> informed companies, the need to keep merge commits fom other lines of
>> development would be quite a common (political ) technique where some
>> preparatory branch needs to be merged in before one's feature can be
>> completed (similar to all those cases on the list when folk say 
>> 'builds on
>> top of xy's commit deadbeaf)
>
> The way we did this at Sun, first with Teamware, then later with
> Mercurial, was as follows:
>
> - "projects" kept their own clone repos of the upstream
> - engineers working on a project cloned the project repo ("project 
> gate")
> - engineers pushed/pulled to/from the project gate
> - each project gate had a gatekeeper whose job it was to periodically
> rebase onto the latest upstream
> - then engineers would rebase onto the new project gate
>
> No "merge turds" (Sun speak) were ever allowed in any upstream,
> whether a project gate or the ultimate upstream.  All commits had to
> be organized according to specific rules, and squashed.  These rules
> applied at the project gate and in the upstream.
>
> - when the project was ready for integration the gatekeeper would
> rebase and squash as necessary, then push to the upstream
>
> (I'm eliding some details.  In particular when an intermediate
> upstream rebased the previous head was left available as a "snapshot"
> to make the equivalent of git rebase --onto possible.)
>
> The upshot was: all local commits were always on top of whatever the
> next upstream in the chain was.  Always.  No merge commits ever.
>
> That workflow works just fine with git.

I'm not saying that it isn't a good technique and can work well. Rather 
I'm saying we should be tolerant of the rules and techniques of others 
who do have 'merges' in their workflow organisation. They may have a 
very long QA delay between feature 'done' and feature 'done done tested 
merged', which requires maintaining merges of done items that aren't yet 
merged to master. Such techniques are more common in mixed engineering 
than pure software environments (where engineering rules apply, and 
software has to follow)

>  It worked really well at Sun
> (with thousands of engineers working on Solaris alone).  And it should
> work well for anyone who doesn't have two or more forked upstreams to
> follow.

I'm just cautious of an accidental one size fits all approach, so the 
ability to rebase lines of development which contain merge commits 
should be possible (with an appropriate and documented option) without 
hidden traps.
>
Philip 

Re: Amending merge commits?

[Nico Williams]

On Tue, Jul 29, 2014 at 2:29 PM, Philip Oakley <philipoakley@iee.org> wrote:
> From: "Nico Williams" <nico@cryptonector.com>
>> Local merge commits mean that you either didn't rebase to keep all
>> your local commits on top of the upstream, or that you have multiple
>> upstreams (the example exception I gave).
>>
>> Conversely, if you always rebase your local commits on top of the
>> upstream then you won't have merge commits to worry about.
>>
> Whilst it may not be "the Git Way", I'd expect that in many less well
> informed companies, the need to keep merge commits fom other lines of
> development would be quite a common (political ) technique where some
> preparatory branch needs to be merged in before one's feature can be
> completed (similar to all those cases on the list when folk say 'builds on
> top of xy's commit deadbeaf)

The way we did this at Sun, first with Teamware, then later with
Mercurial, was as follows:

 - "projects" kept their own clone repos of the upstream
 - engineers working on a project cloned the project repo ("project gate")
 - engineers pushed/pulled to/from the project gate
 - each project gate had a gatekeeper whose job it was to periodically
rebase onto the latest upstream
 - then engineers would rebase onto the new project gate

No "merge turds" (Sun speak) were ever allowed in any upstream,
whether a project gate or the ultimate upstream.  All commits had to
be organized according to specific rules, and squashed.  These rules
applied at the project gate and in the upstream.

 - when the project was ready for integration the gatekeeper would
rebase and squash as necessary, then push to the upstream

(I'm eliding some details.  In particular when an intermediate
upstream rebased the previous head was left available as a "snapshot"
to make the equivalent of git rebase --onto possible.)

The upshot was: all local commits were always on top of whatever the
next upstream in the chain was.  Always.  No merge commits ever.

That workflow works just fine with git.  It worked really well at Sun
(with thousands of engineers working on Solaris alone).  And it should
work well for anyone who doesn't have two or more forked upstreams to
follow.

Nico
--

Re: Amending merge commits?

[Philip Oakley]

From: "Nico Williams" <nico@cryptonector.com>
> On Tue, Jul 29, 2014 at 4:58 AM, Sergei Organov <osv@javad.com> wrote:
>> Nico Williams <nico@cryptonector.com> writes:
>>> That exception aside, keeping all local commits "on top" by always
>>> rebasing them onto the upstream is extremely useful: a) in 
>>> simplifying
>>> conflict resolution, b) making it easy to identify 
>>> as-yet-unintegrated
>>> local commits, c) making it easy to contribute local commits.
>>
>> But 'pull --rebase=preserve' does rebase local commits onto the
>> upstream, and result is exactly the same as 'pull --rebase=true', 
>> unless
>> you have some of your own merges to be rebased. That's where the
>> difference between these two options appears. It's --rebase=false 
>> that
>> performs merges rather than rebase.
>
> Local merge commits mean that you either didn't rebase to keep all
> your local commits on top of the upstream, or that you have multiple
> upstreams (the example exception I gave).
>
> Conversely, if you always rebase your local commits on top of the
> upstream then you won't have merge commits to worry about.
>
Whilst it may not be "the Git Way", I'd expect that in many less well 
informed companies, the need to keep merge commits fom other lines of 
development would be quite a common (political ) technique where some 
preparatory branch needs to be merged in before one's feature can be 
completed (similar to all those cases on the list when folk say 'builds 
on top of xy's commit deadbeaf)

Philip 

Re: Amending merge commits?

[Nico Williams]

On Tue, Jul 29, 2014 at 4:58 AM, Sergei Organov <osv@javad.com> wrote:
> Nico Williams <nico@cryptonector.com> writes:
>> That exception aside, keeping all local commits "on top" by always
>> rebasing them onto the upstream is extremely useful: a) in simplifying
>> conflict resolution, b) making it easy to identify as-yet-unintegrated
>> local commits, c) making it easy to contribute local commits.
>
> But 'pull --rebase=preserve' does rebase local commits onto the
> upstream, and result is exactly the same as 'pull --rebase=true', unless
> you have some of your own merges to be rebased. That's where the
> difference between these two options appears. It's --rebase=false that
> performs merges rather than rebase.

Local merge commits mean that you either didn't rebase to keep all
your local commits on top of the upstream, or that you have multiple
upstreams (the example exception I gave).

Conversely, if you always rebase your local commits on top of the
upstream then you won't have merge commits to worry about.

Nico
--

Re: Amending merge commits?

[Sergei Organov]

Nico Williams <nico@cryptonector.com> writes:

> On Mon, Jul 28, 2014 at 3:00 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:
>> Sergei Organov wrote:
>>
>>> Is there any scenario at all where pull --rebase=true wins over
>>> preserve?
>>
>> Basically always in my book. ;-)
>>
>> When people turn on 'pull --rebase', they are asking for a clean,
>> simplified history where their changes are small discrete patches in a
>> clump on top of upstream.
>
> +1.  Words to develop by.
>
> There are exceptions.  E.g., when you pull commits from multiple
> [forked] upstreams, then you can't keep your local commits on top.
>
> That exception aside, keeping all local commits "on top" by always
> rebasing them onto the upstream is extremely useful: a) in simplifying
> conflict resolution, b) making it easy to identify as-yet-unintegrated
> local commits, c) making it easy to contribute local commits.

But 'pull --rebase=preserve' does rebase local commits onto the
upstream, and result is exactly the same as 'pull --rebase=true', unless
you have some of your own merges to be rebased. That's where the
difference between these two options appears. It's --rebase=false that
performs merges rather than rebase.

Overall, I still can't see where '--rebase=true' wins over
'--rebase=preserve'.

-- 
Sergey.

Re: Amending merge commits?

[Nico Williams]

On Mon, Jul 28, 2014 at 3:00 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Sergei Organov wrote:
>
>> Is there any scenario at all where pull --rebase=true wins over
>> preserve?
>
> Basically always in my book. ;-)
>
> When people turn on 'pull --rebase', they are asking for a clean,
> simplified history where their changes are small discrete patches in a
> clump on top of upstream.

+1.  Words to develop by.

There are exceptions.  E.g., when you pull commits from multiple
[forked] upstreams, then you can't keep your local commits on top.

That exception aside, keeping all local commits "on top" by always
rebasing them onto the upstream is extremely useful: a) in simplifying
conflict resolution, b) making it easy to identify as-yet-unintegrated
local commits, c) making it easy to contribute local commits.

Nico
--