How does git rebase <repo> <branch> apply changes to local

Question

Given:

git remote add upstream https://github.com/source-repo

And a set of K commits from our fork of the source-repo have already been successfully merged into the upstream/master:

eg

 commit C commit C-1 commit C-2 .. commit CK-1 

We want to now rebase the upstream/master back onto our local clone of our fork.

The following commands were attempted:

git checkout our_feature_branch
git fetch -a upstream master
git rebase upstream/master

The result? Merge conflict.

Note: I had verified from github gui and from local editor that

 upstream/master 

and

  local our_feature_branch 

files are identical.

So then what is the git rebase doing? Is it not applying directly the final master/upstream version to the local? ie is it walking through each of the individual commits (that had been squashed by the upstream repo committer btw..) ?

That is the only process that seems to have been possible - given the prior states of both upstream/master and (local clone of fork)/our_feature_branch were:

• identical

• did not contain the text that was displayed in the merge conflict (the text in the conflict was from K-1 commits ago ..)

Answer 1

Run the following command to see the current status of branches:

git remote show upstream

If our_feature_branch is already tracking upstream/master , then git pull should be enough.

git rebase is certainly not just applying directly a commit to another commit. Instead, it takes a series of commits ans places it on top of your commit. It really walks through and changes all rebased commits, so that they all include the changes of your commit (the one to rebase onto).

How a merge conflict is possible here?

Say, there was a file A somewhere back in commit history, and it contained "A". Then in a remote branch it was changed to contain "R". And you changed the same file on your local repo to contain "L".

Now you rebase remote onto your local. The rebase tool has to change the contents of all commits on remote to look like they're done after and on base of your local version. Should it silently overwrite "L" with "R" in the A file?

Answer 2

If there really aren't any differences in the tips, don't rebase. just git checkout -B our_feature_branch upstream/master unless you really really have to remember the two different ways the project arrived at the same content, or git merge upstream/master .

Rebase is applying each rebased commit's changes in sequence to the given tip -- so git's not just seeing the final, non-conflicting content, it's seeing every version of it along the way -- so multiple changes to a hunk in the history are guaranteed to produce at least some conflict with the change that's already there in the new base.

I've never used git imerge , but it looks like that might help a lot if the intermediate histories have diverged too much.

Do git diff upstream/master our_feature_branch --name-status rather than eyeballing it in the editor and gui to detect changes, and git diff -b upstream/master our_feature_branch --name-status to see whether they're due to any kind of whitespace-only changes.