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

On 14 August 2012 10:19, Junio C Hamano [off-list ref] wrote:

Hilco Wijbenga [off-list ref] writes:

quoted

On 14 August 2012 01:27, Thomas Rast [off-list ref] wrote:

quoted

Hilco Wijbenga [off-list ref] writes:

quoted

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

Well, yes, just before pushing, you'd work on master for a few
seconds. That doesn't really count. :-)

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?

That's what I should have said. I assumed way too much context. I
don't think all neurons are firing yet. :-(

quoted

quoted

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

quoted

  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

quoted

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

I was actually looking at "git help merge" since "git help fetch"
would be a far too logical place for FETCH_HEAD information. ;-) As I
said, not all neurons seem to be firing yet.

Apparently, my understanding is mostly correct, though. FETCH_HEAD is
indeed origin/master (I mean the SHA1 in master's HEAD on origin) and
the "git merge" part of "git pull" eventually sets "my" origin/master.

quoted

quoted

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

quoted

quoted

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

I suppose I'm not entirely clear on how this two step process is
"safer". Doing "git fetch" would seem to be harmless, right? So the
problem is with "git merge" but master should always be "behind"
origin/master so that "git merge" should just FF to origin/master
which *should* be completely safe. Does that make sense? Especially
given our use of master as an integration branch?

[Given the trouble I have with getting people to use Git properly, I
prefer things as simple as possible. :-) ]