So let's assume I have the same repository in two different local directories, besides origin. Let's call these localA/master and localB/master. Both of them synchronized with an origin/master.
The log shows this in localA/master and localB/master:
7890858 (HEAD -> master, origin/master) Initial commit
Then I decide to change a file in localA/master, commit it and push it, then pull it in the branch of the other repo localB/master.
75b2345 (HEAD -> master, origin/master) Second commit
7890858 Initial commit
And now, in localA/master I hard-reset it back to 7890858 and force-push it.
+ 75b2345...7890858 master -> master (forced update)
7890858 (HEAD -> master, origin/master) Initial commit
I don't understand why when I do git pull --rebase in localB/master, the message is this:
+ 75b2345...7890858 master -> origin/master (forced update)
Successfully rebased and updated refs/heads/master.
which makes the branch go back to
7890858 (HEAD -> master, origin/master) Initial commit
I mean, I can recreate two situations where I'm working on a local branch with commits A and B and a remote branch with just A, and have different results for git pull --rebase depending on whether there was a forced update or not. There's the case I just described, and then the one where you have only A in remote and A and B in the local branch, except you committed B locally. The latter will tell you Current branch master is up to date.
What's going on here? How can git know if an update must be "forced"? How can I see that myself?
And how does rebase take that into consideration? In both cases I can get a virtually identical log (after git pull), looking like this:
9a5cb91 (HEAD -> master) Second commit, maybe force-pushed
7890858 (origin/master) Initial commit
Yet I can get two different results.