Re: Your branch and 'origin/master' have diverged

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 14, 2012, 17:19 UTC
Message-ID: <7v628lbdcw.fsf@alter.siamese.dyndns.org>
In-Reply-To: <CAE1pOi1YFe9GB1L_==RTecEAipdTKj2-ixpwTnrmOgkkV8rkYw@mail.gmail.com>

Hilco Wijbenga <hilco.wijbenga@gmail.com> writes:

Show 21 quoted lines

> On 14 August 2012 01:27, Thomas Rast <trast@student.ethz.ch> wrote:
>> Hilco Wijbenga <hilco.wijbenga@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.

What a strange thing to say. When will 'master' ever be updated then and how?

If you mean 'master' as the integration branch for everybody to meet and make progress, it would be more common for everybody to be working on his own topic branch until perfection of the topic, concluded by merging the completed topic to master and pushing the master out to update it, no?

Show 18 quoted lines

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

Show 5 quoted lines

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

It could be "git fetch --help" is failing for you, but I am reasonably sure most if not all of the above are answered there; another thing something you may not have known :-).

Show 11 quoted lines

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

Yeah, the latter makes sense, and I think it is a safer superset of the former. If there is nothing of value on 'master', the rebase might stop and give control back to the user, but the user can tell it to skip the cruft that came from the old '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?

As long as you tell what refspecs to use on the command line, the remote nickname behaves as "just an alias for a URL", so yes, because Thomas is discussing "two-arg pull or fetch", one arg being either nickname or URL and the other is an explicit refspec on the command line, it would be okay because there is no difference in that case.