Re: Your branch and 'origin/master' have diverged
On Wed, Aug 15, 2012 at 08:59:02AM +0200, Thomas Rast wrote: I have never had a need for a fetch that doesn't update the remote namespace, nor heard anyone on IRC who has. OTOH, I do have anecdotal evidence in support of the current state is confusing: this thread, or the fact that Jan's IRC bot grew bot-quotes !fetch4/!pull4 that people use to warn users of 'git pull origin master' (it's apparently very common). The 1.8.0 thread is here, and Peff even said he had a patch he uses in his tree: http://thread.gmane.org/gmane.comp.version-control.git/165720/focus=165758 There's even a newer thread suggesting the same: http://thread.gmane.org/gmane.comp.version-control.git/192252 Yeah, I have been running with that patch for ages, and it has never been a problem for me. Of course, the problem cases are very specific workflows that I do not happen to use. There are definitely regressions for some workflows; the question is whether or not anybody is using those workflows (and/or would be bothered to adapt to using the reflog instead). Also note that there are several test failures with the patch, but I haven't investigated them (i.e., I don't know if the patch is buggy, if it is breaking a test in a way that is different than the expected regression, or if the test simply happens to depend on the current behavior and should be fixed). -Peff -- 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
Re: Your branch and 'origin/master' have diverged
On Wed, Aug 15, 2012 at 12:22:28PM -0700, Junio C Hamano wrote: The updated rule would be more complex. If a remote nickname is used, and a refspec given from the command line is without colon, a new special rule overrides the current behaviour and tries to match with a configured refspec. You would need to desribe what happens in that case. It would be something like this. When you tell git fetch to fetch one or more refs from a configured remote by explicitly listing them on the command line, e.g. git fetch remote name... each name... goes through the following process: - The name is turned into the full ref at the remote that starts from refs/ form by applying the usual fetch dwimmery (if name is a name of a branch, refs/heads/name would likely to be the one that is fetched). - Then, configured fetch refspecs for remote is looked up from remote.remote.fetch configuration variable(s), or Pull: line(s) of .git/remotes/remote file. - If the LHS of a refspec found in the previous step matches the full ref we computed in the first step, then the ref at the RHS of the refspec (i.e. remote tracking branch), if any, is updated. If there is no configured refspecs that match the name given from the command line, no remote tracking ref is updated. That is almost exactly what my patch does, except I am not sure that it respects the without a colon bit from your first message. In other words, any time it sees that we have fetched a ref from a particular remote, it applies the mapping from the config and adds the result to the list of refs to be updated. -Peff -- 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
Re: Your branch and 'origin/master' have diverged
Jeff King p...@peff.net writes: On Wed, Aug 15, 2012 at 12:22:28PM -0700, Junio C Hamano wrote: The updated rule would be more complex. If a remote nickname is used, and a refspec given from the command line is without colon, a new special rule overrides the current behaviour and tries to match with a configured refspec. You would need to desribe what happens in that case. It would be something like this. When you tell git fetch to fetch one or more refs from a configured remote by explicitly listing them on the command line, e.g. git fetch remote name... each name... goes through the following process: - The name is turned into the full ref at the remote that starts from refs/ form by applying the usual fetch dwimmery (if name is a name of a branch, refs/heads/name would likely to be the one that is fetched). - Then, configured fetch refspecs for remote is looked up from remote.remote.fetch configuration variable(s), or Pull: line(s) of .git/remotes/remote file. - If the LHS of a refspec found in the previous step matches the full ref we computed in the first step, then the ref at the RHS of the refspec (i.e. remote tracking branch), if any, is updated. If there is no configured refspecs that match the name given from the command line, no remote tracking ref is updated. That is almost exactly what my patch does, except I am not sure that it respects the without a colon bit from your first message. Yeah, I forgot to repeat it in this message, but the above three-bullet list needs the 0-th item - If name has already colon in it, following special case rules do not apply. in front of it. Even though I suspect the updated behaviour may be more useful for casual users (while making the semantics a bit more difficult to explain, like the above documentation update), it is a major regression to existing users if it closes the last escape hatch, so I guess with your patch we are almost there but not quite there yet. -- 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
Re: Your branch and 'origin/master' have diverged
Junio C Hamano gits...@pobox.com writes:
Thomas Rast tr...@student.ethz.ch writes:
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...
Is it?
There already is a way to ask it to update the single tracking
branch while fetching; git fetch origin master that
unconditionally updates refs/remotes/origin/master without a way to
tell it not to do so will be a grave usability regression.
Grave? Do you have any data/use-cases to back that up with?
I have never had a need for a fetch that doesn't update the remote
namespace, nor heard anyone on IRC who has. OTOH, I do have anecdotal
evidence in support of the current state is confusing: this thread, or
the fact that Jan's IRC bot grew bot-quotes !fetch4/!pull4 that people
use to warn users of 'git pull origin master' (it's apparently very
common).
The 1.8.0 thread is here, and Peff even said he had a patch he uses in
his tree:
http://thread.gmane.org/gmane.comp.version-control.git/165720/focus=165758
There's even a newer thread suggesting the same:
http://thread.gmane.org/gmane.comp.version-control.git/192252
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
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
Re: Your branch and 'origin/master' have diverged
Thomas Rast tr...@student.ethz.ch writes:
Junio C Hamano gits...@pobox.com writes:
Thomas Rast tr...@student.ethz.ch writes:
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...
Is it?
There already is a way to ask it to update the single tracking
branch while fetching; git fetch origin master that
unconditionally updates refs/remotes/origin/master without a way to
tell it not to do so will be a grave usability regression.
Grave? Do you have any data/use-cases to back that up with?
When I get a pull request from say Eric, I would:
git fetch git-svn master
git show-branch remotes/git-svn/master FETCH_HEAD
to see what happened since the last pull request on the other side.
He may have rebased (which is not necessarily a crime), or I may see
more commits in the output than what he lists in the request message
(which may indicate I may have missed an earlier pull request from
him).
Such a sanity check will stop working if the first fetch updated
my remotes/git-svn/master. I would have to enable reflog for
tracking branch and do something like this:
git show-branch remotes/git-svn/master@{1} remotes/git-svn/master
So I was correct in saying that without an easy escape hatch, such a
change would be a regression.
But I think I (and others) could just train fingers to do
git fetch git-svn master:
as a workaround.
Updating Documentation/pull-fetch-param.txt would be a bear, though.
The documentation is stale in that it was written in the days back
when .git/remotes/ was the primary way to configure remotes, and was
not adjusted to use the termilology used in the [remote where]
section of the .git/config file (notice a mention of 'Pull: '
lines there), so it needs cosmetic adjustment anyway, but the
semantics it spells is still up to date. The current rule is very
simple and understandable. You either say from the command line
exactly what should happen (refspec without colon is the same as the
refspec with colon at the end, meaning do not track; if you want
to track, you write what to update with the fetch), or we use the
configured refspec (which again spells what should happen).
The updated rule would be more complex. If a remote nickname is
used, and a refspec given from the command line is without colon, a
new special rule overrides the current behaviour and tries to match
with a configured refspec. You would need to desribe what happens
in that case.
--
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
Re: Your branch and 'origin/master' have diverged
Holger Hellmuth (IKS) hellm...@ira.uka.de writes: Am 15.08.2012 19:30, schrieb Junio C Hamano: The current rule is very simple and understandable. You either say from the command line exactly what should happen (refspec without colon is the same as the refspec with colon at the end, meaning do not track; if you want to track, you write what to update with the fetch), or we use the configured refspec (which again spells what should happen). Couldn't a similar new rule just say that refspec name is a short for name:name ? Of course not. -- 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
Re: Your branch and 'origin/master' have diverged
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?
Or perhaps the real reason for the divergence is that upstream rewrote
its master (k!), in which case you should get them acquainted with
the clue bat... and probably rebase instead of merge.
* 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.
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!
* 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.
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
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
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
Re: Your branch and 'origin/master' have diverged
On Mon, Aug 13, 2012 at 12:58 PM, Hilco Wijbenga hilco.wijbe...@gmail.com wrote: Hi all, A colleague of mine (after a relatively long absence) noticed the following when running git status: # 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. Well, not this one. This one is persistent. :-) I am at a loss what to do. master and origin/master do *not* point at the same commit. Even after the git reset --hard ... and git pull. Running my silver bullet solution gets us in the same situation every time. I assume that the commit you reset to wasn't actually before the divergence, then. It sounds like what you're trying to do is just long-hand for 'git reset --hard origin/master'. As mentioned before, that *does* assume that you want to throw out everything you've committed locally. If that's *not* the case, try 'git rebase origin/master' or 'git pull --rebase'. And then go slap the person who rewrote the history of origin/master. -PJ Gehm's Corollary to Clark's Law: Any technology distinguishable from magic is insufficiently advanced. -- 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
Re: Your branch and 'origin/master' have diverged
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 (k!), 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
Re: Your branch and 'origin/master' have diverged
On 14 August 2012 09:02, PJ Weisberg p...@irregularexpressions.net wrote: On Mon, Aug 13, 2012 at 12:58 PM, Hilco Wijbenga hilco.wijbe...@gmail.com wrote: Hi all, A colleague of mine (after a relatively long absence) noticed the following when running git status: # 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. Well, not this one. This one is persistent. :-) I am at a loss what to do. master and origin/master do *not* point at the same commit. Even after the git reset --hard ... and git pull. Running my silver bullet solution gets us in the same situation every time. I assume that the commit you reset to wasn't actually before the divergence, then. It was according to gitk. It sounds like what you're trying to do is just long-hand for 'git reset --hard origin/master'. As mentioned before, that *does* assume that you want to throw out everything you've committed locally. If that's *not* the case, try 'git rebase origin/master' or 'git pull --rebase'. And then go slap the person who rewrote the history of origin/master. I'm not convinced anything is wrong with origin/master. This particular colleague is the only one with a problem. And not for the first time. :-) -- 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
Re: Your branch and 'origin/master' have diverged
Hilco Wijbenga hilco.wijbe...@gmail.com writes: 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. 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. -- 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
Re: Your branch and 'origin/master' have diverged
On 14 August 2012 10:19, Junio C Hamano gits...@pobox.com wrote: Hilco Wijbenga hilco.wijbe...@gmail.com writes: 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. 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. :-( * 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 :-). 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. 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. 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. :-) ] -- 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
Re: Your branch and 'origin/master' have diverged
Hilco Wijbenga hilco.wijbe...@gmail.com writes: 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. :-) ] Between the two procedures Thomas gave you, fetch rebase is safer than fetch reset --hard, exactly because it does not have to rely on the validity of your which should always be behind claim. If it is behind, there won't be any difference, but if it is *not*, the user will notice and won't lose his work on 'master' (which you may argue that he shouldn't have done). rebase will notice it. The key for a procedure to be safe is not having to rely on the claim of users such as my history *should* always and already be behind, and not silently lose information when these *should*s are violated for whatever reason. After all, if all these *should*s were true, the user wouldn't have been having problems in the first place and posting to the list asking for help in the first place ;-) -- 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
Re: Your branch and 'origin/master' have diverged
Hilco Wijbenga hilco.wijbe...@gmail.com writes:
On 14 August 2012 10:19, Junio C Hamano gits...@pobox.com wrote:
Hilco Wijbenga hilco.wijbe...@gmail.com writes:
On 14 August 2012 01:27, Thomas Rast tr...@student.ethz.ch wrote:
[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
--
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
Re: Your branch and 'origin/master' have diverged
Thomas Rast tr...@student.ethz.ch writes: 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... Is it? There already is a way to ask it to update the single tracking branch while fetching; git fetch origin master that unconditionally updates refs/remotes/origin/master without a way to tell it not to do so will be a grave usability regression. -- 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
Re: Your branch and 'origin/master' have diverged
On 14 August 2012 13:12, Thomas Rast tr...@student.ethz.ch wrote: Hilco Wijbenga hilco.wijbe...@gmail.com writes: On 14 August 2012 10:19, Junio C Hamano gits...@pobox.com wrote: Hilco Wijbenga hilco.wijbe...@gmail.com writes: On 14 August 2012 01:27, Thomas Rast tr...@student.ethz.ch wrote: [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. ;-) -- 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
Re: Your branch and 'origin/master' have diverged
Hilco Wijbenga hilco.wijbe...@gmail.com writes: 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). Now it is really the time for you to go back to git fetch --help and read up on refspecs. With $ git fetch origin you are not telling fetch what to fetch, so it goes to your .git/config and finds remote.origin section to find what refspec to use. They would say something like [remote origin] url = ... fetch = refs/heads/*:refs/remotes/origin/* meaning (see the manual) fetch all the branches there, store them with the corresponding name under refs/remotes/origin. With $ git fetch origin master you are overiding the refspec in .git/config and explicitly saying I want to fetch the master branch, but do not want to update anything with it. It is a short-hand for $ git fetch origin refs/heads/master which in turn is a short-hand for $ git fetch origin refs/heads/master: If you wanted to update the tracking ref, you would use a refspec with non-empty strings on the both sides of colon, i.e. $ git fetch origin master:refs/remotes/origin/master -- 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
Your branch and 'origin/master' have diverged
Hi all, A colleague of mine (after a relatively long absence) noticed the following when running git status: # 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. Well, not this one. This one is persistent. :-) I am at a loss what to do. master and origin/master do *not* point at the same commit. Even after the git reset --hard ... and git pull. Running my silver bullet solution gets us in the same situation every time. I checked his .git/config and it looks fine. Any ideas? What information should I provide that might make it possible for you to help me? Cheers, Hilco -- 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
