Re: Amending merge commits?

[Nico Williams <nico@cryptonector.com>]

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
--