On 14 August 2012 01:27, Thomas Rast <tr...@student.ethz.ch> wrote:
> Hilco Wijbenga <hilco.wijbe...@gmail.com> 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?

Of course, it's master. Nobody should be working on master directly.

>   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.

Upstream is fine. Nobody else is having any problems.

> * 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.

Yes, I know.

>   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!

Ah, now we're getting to something I did *not* know. :-) So FETCH_HEAD
!= origin/master? I tried to find out more information about
FETCH_HEAD but there doesn't seem to be much. I have seen "FETCH_HEAD"
show up in the terminal but always just ignored it as a Git
implementation detail. When/how does origin/master get set then? I
always assumed that was part of git fetch and then git merge would
actually move master to origin/master.

> * 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.

:-) Well, yeah, now that you point it out... :-)

Still, just resetting ignores all the problems that led to the current
situation. Normally, when I reset and then FF I can be sure (if it
works) that things were not completely screwed up. At least, that has
always been my theory.

> 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

Why would that be okay? What is the difference? Isn't the nickname
just an alias for a URL?
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to