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

2 messages, 2 authors, 2016-06-15 · open the first message on its own page

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

From: Thomas Rast <hidden>
Date: 2016-06-15 22:54:29

Hilco Wijbenga [off-list ref] writes:
On 14 August 2012 10:19, Junio C Hamano [off-list ref] wrote:
quoted
Hilco Wijbenga [off-list ref] writes:
quoted
On 14 August 2012 01:27, Thomas Rast [off-list ref] wrote:
quoted
[git pull with two args] 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. :-) ]
I meant something else than Junio hinted at.  Saying

  git fetch origin master
  # or by extension
  git pull origin master

does not update the origin/* namespace, not even origin/master.  All
fetching happens only into FETCH_HEAD.  This leads to confusion such as
yours because origin/master and thus the upstream tracking displays will
not know about the change.

If you use it with an URL, such as one that might be sent with a pull
request:

} The following changes since commit 62bc83349d52be49b037d2c800a7f4064cfbc5b5:
} 
}   The sixth batch of topics graduated to 'master' (2012-04-27 14:12:56 -0700)
} 
} are available in the git repository at:
} 
}   https://github.com/git-l10n/git-po/ master

(I picked a random pull request from the l10n coordinator, Jiang Xin)
you would say

  git pull https://github.com/git-l10n/git-po/ master

and you would not have a reasonable expectation of git updating your
remotes/*, even if you had a remote 'l10n' that points at that exact
URL.  So you would not be confused if you pulled from there, but
l10n/master didn't move.


In some sense this is a really bad case of wrong UI design, because we
(this happens on #git a lot) have to teach users not to use the command
so they won't trip over this problem.  It would be better to fix the
real issue instead.  IIRC it was even on the 1.8.0 wishlist...

-- 
Thomas Rast
trast@{inf,student}.ethz.ch

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

From: Hilco Wijbenga <hidden>
Date: 2016-06-15 22:54:29

On 14 August 2012 13:12, Thomas Rast [off-list ref] wrote:
Hilco Wijbenga [off-list ref] writes:
quoted
On 14 August 2012 10:19, Junio C Hamano [off-list ref] wrote:
quoted
Hilco Wijbenga [off-list ref] writes:
quoted
On 14 August 2012 01:27, Thomas Rast [off-list ref] wrote:
quoted
[git pull with two args] 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. :-) ]
I meant something else than Junio hinted at.  Saying

  git fetch origin master
  # or by extension
  git pull origin master

does not update the origin/* namespace, not even origin/master.  All
fetching happens only into FETCH_HEAD.  This leads to confusion such as
yours because origin/master and thus the upstream tracking displays will
not know about the change.
I'll say. Now I'm really confused.

If what you say is true then what is updating origin/master? I've been
using "git pull" daily for over a year and origin/master is definitely
getting updated (at least according to gitk).

Mmm, just to make sure we are all talking about the same
origin/master: I mean my local reference to the SHA1 of the commit
that is master's HEAD on origin. After I have run "git pull",  *my*
master and *my* origin/master point to the same commit. Or I'm
*really* confused. Or I've confused you by using incorrect
terminology. :-) Or by using the right terminology incorrectly. ;-)
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help