Re: Your branch and 'origin/master' have diverged
- From
- Hilco Wijbenga <hilco.wijbenga@gmail.com>
- Date
- Aug 14, 2012, 17:04 UTC
- Message-ID
- <CAE1pOi1YFe9GB1L_==RTecEAipdTKj2-ixpwTnrmOgkkV8rkYw@mail.gmail.com>
- In-Reply-To
- <87zk5x6fox.fsf@thomas.inf.ethz.ch>
On 14 August 2012 01:27, Thomas Rast <trast@student.ethz.ch> wrote:
Show 18 quoted lines
> 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.
> 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.
Show 9 quoted lines
> 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.
Show 14 quoted lines
> 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?