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
