Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

bozzzzo
Copy link

@bozzzzo bozzzzo commented Oct 23, 2015

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
Copy link
Owner

mhagger commented Oct 30, 2015

Thanks for the patch! ✨

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
Copy link
Author

bozzzzo commented Oct 30, 2015

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
Copy link
Owner

mhagger commented Oct 30, 2015

@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 New concept: "simplify to path" #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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants