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

> Hilco Wijbenga <hilco.wijbenga@gmail.com> writes:
>
>> 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?

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

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