git rebase -p doesn't understand -X

git rebase -p doesn't understand -X

[Marius Storm-Olsen]

Hi,

I'm trying to rebase a rather large series of patches, which also 
contains a couple of merges which I'd like to recreate in the rebase, 
and for the other conflicts I'd like git to automatically choose 'ours'.

So, I run
     git rebase -p -X ours -X patience -X ignore-all-space --onto foo 
bar baz
and I get
     error: unknown switch `X'

Clearly this is because when you use the -p option, everything goes 
through the --interactive engine, instead of the normal procedure. I 
would still like to maintain that this is a bug, and that even though -p 
uses a different engine, to be able to recreate the merges, it should 
still be able to let me tune the overall merge strategy.

Is there any work around to allow me to achieve the same result?

Thanks!

-- 
.marius

Re: git rebase -p doesn't understand -X

[Martin von Zweigbergk]

On Fri, Apr 15, 2011 at 7:21 PM, Marius Storm-Olsen <mstormo@gmail.com> wrote:
> Hi,
>
> I'm trying to rebase a rather large series of patches, which also contains a
> couple of merges which I'd like to recreate in the rebase, and for the other
> conflicts I'd like git to automatically choose 'ours'.
>
> So, I run
>    git rebase -p -X ours -X patience -X ignore-all-space --onto foo bar baz
> and I get
>    error: unknown switch `X'

Interactive rebase uses cherry-pick internally. Jonathan added support
for -X to that command not too long ago (in commit 67ac1e1, late last
year), so it should be pretty straight-forward to add support for what
you want. Maybe I'll do that in a few weeks when I get back from
vacation.

A related topic is _when_ to use the strategy (and strategy options).
I asked the question on
http://thread.gmane.org/gmane.comp.version-control.git/164241/focus=164543,
but I will try to clarify here.

I saw that when rebase -p was initially introduced by Johannes in
f09c9b8 in 2007, he gave this example:


    Example:

               X
                \
             A---M---B
            /
    ---o---O---P---Q

    When the current HEAD is "B", "git rebase -i -p --onto Q O" will yield

                   X
                     \
    ---o---O---P---Q---A'---M'---B'


Is that similar to what you want? I have normally been thinking about
an example that looks more like:

               C---D
              /     \
             A---B---M
            /
    ---o---O---P---Q

which would yield

                         C'---D'
                        /       \
    ---o---O---P---Q---A'---B'---M'


In such a case, it probably makes sense to use the same strategy to
create A' through D', because the upstream change for all of them
would be the changes from O to Q (the merge base is O). However, when
applying M to form M', that part of the history is not involved (the
merge base is A').

Would it be completely insane to stop passing the strategy when
recreating merges? It seems to me that it would at least be better in
the second example above. Johannes, do you think that would break
things in the first example?

A more advanced solution would be recreate the merge using rerere. We
could first redo the merge from D to B and reset the tree to look like
in M, then record the resolutions and reuse them when doing the merge
to form M'. Makes sense? Overkill? If we want to avoid interfering
with the normal rerere cache, I guess we could use a separate rerere
cache (which I don't think is currently supported).

> Is there any work around to allow me to achieve the same result?

Not that I know of. (Except, of course, piece-wise rebasing the linear
parts of history and doing the merges manually.)


/Martin

Re: git rebase -p doesn't understand -X

[Jonathan Nieder]

Hi Martin,

Martin von Zweigbergk wrote:

> Interactive rebase uses cherry-pick internally. Jonathan added support
> for -X to that command not too long ago (in commit 67ac1e1, late last
> year), so it should be pretty straight-forward to add support for what
> you want. Maybe I'll do that in a few weeks when I get back from
> vacation.

That would be excellent.

> A related topic is _when_ to use the strategy (and strategy options).

I agree with your analysis.  In particular:

>     Example:
>
>                X
>                 \
>              A---M---B
>             /
>     ---o---O---P---Q
>
>     When the current HEAD is "B", "git rebase -i -p --onto Q O" will yield
>
>                           X
>                            \
>     ---o---O---P---Q---A'---M'---B'

I have a vague feeling that honoring --strategy and --strategy-option
would be confusing here.  The merge used in cherry-picking A does not
have much to do with the merge used to reincorporate changes from X.

Well, that is my intuition, but most of the examples I can think of
lead to the opposite conclusion!  If I use -Xrenormalize, because P
changed the line-ending style, then I will want the same option when
merging X on top.  Similarly, if I use -Xsubtree=src, because Q moved
all existing files in the source tree under src/, then with luck the
same trick will work when replaying the merge of X.

Luckily there is an exception to prove the intuition ok.  If X was the
first parent of M and I am using -Xours to sloppily favor upstream's
decisions when rebasing my history on top of it, using -Xours to favor
choices from X (which is my own) would be just plain wrong.  (Phew.)
 
>                C---D
>               /     \
>              A---B---M
>             /
>     ---o---O---P---Q
>
> which would yield
>
>                           C'---D'
>                          /      \
>     ---o---O---P---Q---A'---B'---M'

Likewise in this case.

> A more advanced solution would be recreate the merge using rerere.
[...]

Here's a vague and probably wrong idea about another way to re-create
merges.

When cherry-picking a patch (A, say), we run a three-way merge, with
A^ as merge base, A as "their" change, and the new parent for A (= Q)
as "our" change.

Maybe the same trick could work for re-creating merges.  In your first
example, run a three-way merge with M^ (= A) as merge base, M as
"their" change, and the new parent for M (= A') as "our" change.  That
only works in such a straightforward way if only one of M's parents
was rewritten, though.  More generally it could be possible to run a
sequence of three-way merges:

	base=M^1, theirs=M, ours=(M^1)' => call the result "m_1"
	base=M^2, theirs=m_1, ours=(M^2)' => call the result "m_2"
	...

At this point it gets ugly enough that just redoing the merge might be
simpler.

The main problem with rerere is that it can make mistakes.  In the
long run, I wonder if rebase could learn to take into account
something more explicit like Junio's merge-fix mechanism (see
origin/todo:Reintegrate).

Thanks; that was interesting.
Jonathan