From: Junio C Hamano <gitster@pobox.com>
Date: Sat, 24 Nov 2012 02:58:49 GMT
Subject: Re: [RFC/PATCH] Option to revert order of parents in merge commit
Message-ID: <7vfw3zzoye.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20121123083550.GA702@camk.edu.pl>

Kacper Kornet <draenog@pld-linux.org> writes:

> The following patch is an attempt to implement this idea.

I think "revert" is a wrong word (implying you have already done
something and you are trying to defeat the effect of that old
something), and you meant to say "reverse" (i.e. the opposite of
normal) or something.

I am unsure about the usefulness of this, though.

After completing a topic on branch A, you would merge it to your own
copy of the integration branch (e.g. 'master') and try to push,
which may be rejected due to non-fast-forwardness:

    $ git checkout master
    $ git merge A
    $ git push

At that point, if you _care_ about the merge parent order, you could
do this (still on 'master'):

    $ git fetch origin
    $ git reset --hard origin/master
    $ git merge A
    $ test test test
    $ git push

With --reverse-parents, it would become:

    $ git pull --reverse-parents
    $ test test test
    $ git push

which certainly is shorter and looks simpler.  The workflow however
would encourage people to work directly on the master branch, which
is a bit of downside.

Is there any interaction between this "pull --reverse-parents"
change and possible conflict resolution when the command stops and
asks the user for help?  For example, whom should "--ours" and "-X
ours" refer to?  Us, or the upstream?