On 14 August 2012 01:27, Thomas Rast <trast@xxxxxxxxxxxxxxx> wrote: > Hilco Wijbenga <hilco.wijbenga@xxxxxxxxx> 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 (eeeek!), 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html