Hilco Wijbenga <[email protected]> writes:
> # On branch master
> # Your branch and 'origin/master' have diverged,
> # and have 250 and 19 different commit(s) each, respectively.
> #
> nothing to commit (working directory clean)
>
> He asked me what to do and I told him to do what has always worked for
> me in the past when something like this happened: gitk, "reset master
> branch to here" (to a commit before the divergence and using --hard),
> git pull origin master. Problem solved.
There are several layers of pitfalls and misunderstandings here.
* Is your work origin/master..master (that is, anything in master but
not origin/master) really so worthless as to make "scrap it all!" the
normal course of resolution?
Or perhaps the real reason for the divergence is that upstream rewrote
its master (eeeek!), in which case you should get them acquainted with
the clue bat... and probably rebase instead of merge.
* pull = fetch + merge! Repeat this a few times until it sinks in.
Then print it on A0 and stick it up in your office or something.
For your case this means that the pull command is roughly equivalent
to
git fetch origin master
git merge FETCH_HEAD
The two-arg form of fetch does *not* update origin/master. Assuming
you got the reset right, the merge will fast-forward to whatever
origin's master points to -- but origin/master is still the old state!
* Resetting to something that you think will fast-forward, only to then
fast-forward it to the newest state, is silly. You can just reset to
the newest state instead.
Taking all of this together, I think you should stop using two-arg
pull[*] or fetch, and replace your error-prone recipe with simply
git fetch
git reset --hard origin/master
Assuming, as before, that your local work is worthless. Is it?
Otherwise it would be better to run something like
git fetch
git rebase origin/master
[*] it's ok if you use it with an URL instead of a remote nickname
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
