rebase-reversed goal for those struggling with what gets rebased where

[bozzzzo]

Given the fact that all the information is already present and all the hard work was already done it seemed easier to extend the tool than to redo the merge work.

A messy merge is really more manageable with git-imerge...

[mhagger]

Thanks for the patch! :sparkles:

I agree that

git imerge start --goal=rebase --first-parent BRANCH

is confusing, because it is backwards to the direction of git rebase; it rebases BRANCH on top of the current branch rather than the other way around.

But doesn't

git imerge rebase BRANCH

do the thing that you want (i.e., equivalent to git rebase BRANCH)? Personally, I always use the latter and never the former. If you help me understand the use case it will be easier to evaluate your PR.

Thanks!

[bozzzzo]

This patch solves a PEBKAC (me in this case) where I sometimes still get confused by git rebase moving the branch I am on, and not the branch I specify...

So I was on master branch and did a git-imerge rebase side-branch. If I were doing a plain git rebase I would just have to do it again. But with git-imerge I had the correct rebase results also done only there was no command to access the other one...

[mhagger]

@bozzzzo: Thanks for the explanation. That makes sense and I can see that it would be a useful feature.

Regarding the patch itself:

1. It is an awful lot of copy-paste. I think it makes sense to extract some functions first to reduce the amount of duplication. I just pushed a branch simplify-to-path in PR #90 that does so. If I then merge that branch into yours, the result is my rebase-reversed branch (though I haven't tested it at all).
2. The new feature would need documentation in README.rst.
3. There are some consistency checks done for rebases (for example, here and here which I think would also be needed for rebase-reversed.
4. Given that --goal=rebase is actually kindof reversed relative to what git rebase does, I wonder whether naming this feature rebase-reversed will introduce even more confusion. I wonder if a better name might make this clearer. At the same time we might even want to deprecate --goal=rebase and give that operation a more intuitive name, too.