undefined | Better HN

0 pointsSharlin4d ago0 comments

  git checkout mybranch
  git rebase main

Now git takes main and starts cloning (cherry-picking, as you said) commits from mybranch on top of it. From git's viewpoint it's working on top of main, so if a conflict occurs, main is "ours" and mybranch is "theirs". But from your viewpoint you're still on mybranch, and indeed are left on mybranch when the rebase is complete. (It's a different mybranch, of course; once the rebase is completed, git moves mybranch to point to the new (detached) HEAD.) Which makes "ours" and "theirs" exactly the opposite of what the user expects.

0 comments

orthoxerox4d ago

I had to make an alias for rebasing, because I kept doing the opposite:

    git checkout master #check out the branch to apply commits to
    git rebase mybranch #Apply all commits from mybranch

Now I just write

    rebase-current-branch

and it does what I want: fetches origin/master and rebases my working branch on top of it.

But "ours"/"theirs" still keeps tripping me up.

skydhash3d ago

You can use the --onto flag for git rebase

  git rebase --onto origin/master

It will checkout origin/master and replay the current branch on top.

P.S. I had to check the man page as I use Magit. In the latter I tap r, then u. In magit my upstream is usually the main trunk. You can also tap e instead of u to choose the base branch.

cerved3d ago

Tip, you may want to use origin/HEAD over origin/master

orthoxerox3d ago

Is it the naming-independent identifier of the tip of the trunk?

XorNot4d ago

Man do I hate this behavior because it would be really some by just using the branch names rather then "ours" and "theirs"

SharlinOP3d ago

Agreed. Even when the branch is the same, it would always be distinguishable by <remote-name>/<branch-name> vs. just <branch-name>.

j / k navigate · click thread line to collapse