bad git pull

Hello,

I notice if I create a branch (and switch to it) in the linux kernel off of say version 2.6.14, then later do a git pull, things get ugly. It seems like all the upstream changes are being merged into the 2.6.14 branch (instead of the latest kernel tag).

Is this a user error because the tool is still fragile?

Thanks, Don

Don Zickus <dzickus@gmail.com> writes:

I do not understand the question.

The user wanted all the good developments from the mainline into the fork he created starting at 2.6.14, and the tool did what was asked. Why would you want to forbid that from happening, and what did you want to happen instead?

Junio C Hamano <junkio@cox.net> writes:

Actually I think I do understand the question. You have a clone of linux-2.6 repository, and your "origin" branch tracks the bleeding edge from Linus. You also have "myhack" branch that was forked off from 2.6.14, and wanted to see what new things Linus has by updating "origin", and perhaps merge those changes into your "master" which keeps track of your hacks based on Linus tip, but unfortunately you were on "myhack" branch.

Ouch.

So what you wanted to do was probably:

	$ git fetch ;# this updates "origin" to Linus tip

instead of

	$ git pull ;# this updates "origin" to Linus tip *and*
                    # merges that into the current branch

As you may probably know, you can recover by

	$ git reset --hard

While I am sympathetic, this "Oops, I said pull when I meant fetch" sounds remotely similar to "oops, I said 'rm -r' when I meant to say 'ls -r'". Is it that the tool is too fragile?

Sorry, wrong choice of words. Didn't mean to imply anything negative. Though, I am still learning the tool and its features, I do appreciate your feedback and your last email was correct in understanding the mess I created. I'll go read up on the differences between 'fetch' and 'pull'.

Cheers, Don

Don Zickus <dzickus@gmail.com> writes:

I too was a bit too defensive, and I agree the tool is prone to easy errors; the worst part is that there is no "rm -i" equivalent to be extra careful [*1*]. On the other hand, we have "git reset" to recover from, so it is not as bad as a mistake with "rm" ;-).

If for example there were a way to say "this `origin' shortcut is to be pulled into `master' branch and nothing else", we could have caught the "git pull" you had trouble with. There was a discussion on the list in the past to extend remotes/ files to allow such restriction of the patchflow to be expressed, but back then I felt the kind of restriction the proposal could express was too limiting, and the discussion was a bit premature because we did not have recommended patterns yet.

We might want to revive the discussion post 1.0. Taking the example of the topic-branch workflow by Tony, the "patch flow" language needs to be able to express something at least this:

 - topic branches -- branched from 'origin' somewhere in the
   past; commits accumulated but usually nothing is merged
   into them.

 - 'test' -- branched from 'origin' somewhere in the past; used
   solely to merge topic branches into it and no commits are
   made into it directly; branches that are regularly merged
   into it are:

   - topic branches
   - 'origin'
   - 'release'

 - 'release' -- branched from 'origin' somewhere in the
   past; trivial/obviously correct commits are made into it
   directly; proven to be good topic branches are merged into it
   for consumption by others; branches that are regularly merged
   into it are:

   - topic branches
   - 'origin'
   - never 'test' 

[Footnote]

*1* IMHO "rm -i" is not that safe, though. If one overuses it, it trains one's fingers to say "y" without much thinking.

Hello,

Here are my two cents. I'll try my best to make a case for those poor souls who get into this sort of mess.

Whenever I give a colleage an introduction to git I emphatically recommend that they start with using git fetch and git merge independantly of each other and stay away for git pull at least until they know what they're doing. This is because I have found that people are really surprised at what happens when they type git pull until it really sinks in that 'pull = fetch + merge to current branch, whatever that may be'.

The difference between the words fetch and pull is much more subtle than the difference between remove and list which are the basis for the commands rm and ls. I see nothing in the English dictionary to suggest that pull means fetch + merge. This is a gitism. Even after reading documentation clearly and even using git for a while the difference really takes some time to sink in.

I think a great degree of understanding should be shown toward those who dig themselves into this kind of thing. I also recommend that some extra care should be taken in the tutorials and documentation to warn about this difference up front and possibly suggest avoiding the use of pull for those new to git.

Carl

PS The issue was exacerbated when cogito and git were inconsistent on their respective usages of pull and fetch. I think this has gone away, hasn't it? I haven't used cogito in some time so I really don't know.

On Thu, Dec 15, 2005 at 03:53:38PM -0800, Junio C Hamano wrote:

Carl Baldwin <cnb@fc.hp.com> writes:

You "reduced" this sequence:

	$ git symbolic-ref HEAD ;# to make sure you are on the branch
                                 # you think you are on
	$ git pull

to this sequence:

	$ git fetch origin      ;# would not damage the repository
	$ git symbolic-ref HEAD ;# to make sure you are on the branch
                                 # you think you are on
	$ git merge "Merge from frotz branch of git://..." HEAD FETCH_HEAD

The thing is, you need to make sure where you are, in either case, before the actual merge happens. Yours needs extra typing, and in addition loses the merge message autogenerated by "git pull". Sorry, I fail to see how that is an improvement.

I agree to this. I have never used BK so this is just a speculation, but I suspect what happened is that we inherited "pull" terminology from there, needed to name the merge-less part something, and we ended up calling it "fetch". So the history behind them might be expressed better by "fetch = pull - merge" instead of saying "pull = fetch + merge" ;-).

Yup. Thanks for the comments. I am not a good writer, so a patch is greatly appreciated.

BTW, I feel that setting Mail-Followup-To: to other people is just plain rude.

    Mail-Followup-To: Junio C Hamano <junkio@cox.net>,
            Don Zickus <dzickus@gmail.com>, git@vger.kernel.org

I suspect you are trying to avoid receiving a duplicate message because you subscribe to the list, but when I tell my MUA "I want to say something to the author of this message in public" I get Don Zickus on the To: line instead of you, and I had to edit the To: line to point at you. Aren't you forcing me (and other people who might want to follow-up to your message) to do extra work, and making Don's life harder [*1*], just to work around the problem on your end, when you could just filter the incoming duplicates yourself?

Removing yourself from CC: line when the CC: line already contains the mailing list you subscribe to would be fine, but I find this use of Mail-Followup-To: somewhat objectionable.

[Footnote]

*1* Don could have a mail sorter that prioritizes messages addressed To: over Cc: him, and response meant to *you* goes with To: Don --- which messes up such a mail sorting rule.

Didn't bk come with some kind of (one-level) undo pull? It should not be too hard to create something similar considering that one could just leave new objects in the db orphaned.

M.

Morten Welinder <mwelinder@gmail.com> writes:

Yes, that is called "git reset".

On Fri, 16 Dec 2005, Junio C Hamano wrote:

Well, this is one area where BK and git differ a lot. BK didn't overload many things onto the same "reset" functionality, but had specific operations for specific cases.

Also BK would never leave a merge in the git kind of half-merged state, because BK refuses to have two branches open. Instead, BK had a special way of handling merges, which worked fine but quite frankly I have very little idea of how it worked (it was some kind of "shadow BK tree", it was called ".bk/RESOLVE/" or something like that - but because the tools were so nice, you never really had any reason to look into it, so I don't know what it did).

BK would never change the working tree itself until the merge was done, so you would never need to do what a plain "git reset --hard" (without any arguments) does.

In many ways the BK thing was very nice, although the git way is perhaps a bit more flexible (because git makes the intermediate tree visible you can easily edit the merge errors, and compile/test the result, before you decide to commit any manual merge).

I really do like the way git does merges now (especially after the last round of git-diff-tree fixes that allow comparing the different stages), but the BK way is in some ways cleaner and leaves less potential for confusion since it avoids ever exposing you to any half-merged state.

You may remember how I initially argued that we should always try to merge stuff outside of the normal working directory. And I still _like_ that approach, although I've since decided that I actually prefer the current git way is even better in practice.

But "git reset" is a lot more than the "revert to previous state". It _also_ does - without the error checking - what "bk fix" used to do (which is to undo the last commit, so that you can re-commit it), and it also does what "bk undo" used to do. It also does "bk unpull".

So "git reset" really does a whole lot of different and _mostly_ related things:

 - undo any half-way changes (very similar to just "git checkout -f"), and 
   just reset to the state of the last successful commit (ie "current 
   HEAD"):

	git reset --hard

   BK didn't need this, although if you just want to remove your edits 
   (which "git reset --hard" also does), you could - like with git - just 
   do a "checkout" operation, of course.

 - undo the last commit, but don't undo the working tree ("soft reset to
   parent of head").

	git reset HEAD^

   I think this was "bk fix -C".

 - undo the last commit entirely ("hard reset to previous state"):

	git reset --hard HEAD^

   This was "bk undo"

 - undo the last pull ("bk unpull"): "hard reset to ORIG_HEAD":

	git reset --hard ORIG_HEAD

   This was "bk unpull".

where the last two are obviously just special cases of a generic "undo to arbitrary previous commit state".

BK in many ways had more hand-holding (which I think is good, and "git" to some degree has an unnecessarily "hard core" approach to these things).

For example, I think "bk undo" not only asked you about it, but it also only ever undid the last commit (and refused to undo a pull or merge). If you wanted to undo to some arbitrary state, you had to use the "-a" flag, iirc.

Of course, under BK the "undo" operation was final, so BK _had_ to be more careful. With git, if you undo to some arbitrary state, you can still "re-do" all your commits if you just find the old head (and git-fsck-objects will help you do that), so in that sense git doesn't _need_ to be as careful as BK was.

		Linus

It would be outright peachy if Documentation/git-commit.txt and Documentation/git-pull.txt mentioned these. That is certainly where I would look first to answer the "what if I screwed up?" question.

Morten

On Fri, 16 Dec 2005, Morten Welinder wrote:

It might be even better to have some of the "safe" versions around. Ie something that refuses to "undo" a merge (you want to "unpull" it or "unmerge" it), and refuses to "undo" when there's a ORIG_HEAD around that implies that the last commit was a "pull" (in which case again "undo" may be the wrong thing to do, since it will only undo _one_ commit, even though the pull might have fast-forwarded a _lot_ of commits).

Of course, if we do that, we should also make sure that "git commit" removes ORIG_HEAD.

Or maybe "git commit" should always _write_ ORIG_HEAD with the old head, so that we can always do an "undo" by doing "git reset --hard ORIG_HEAD" regardless of whether the last thing was a "git commit" or a "git pull".

Hmm?

		Linus

Linus Torvalds <torvalds@osdl.org> writes:

If we define "git undo" as "Revert the tree to the state one before the last successfull commit/pull", then overwriting ORIG_HEAD as you say at the commit time and always using "git reset --hard ORIG_HEAD" would make sense.

I fail to see the merit of "git undo/unpull/unmerge/..."; mostly because I have never seen BK and do not benefit from the familiarity factor at all. To people without BK experience, having too many synonyms (e.g. "git undo" does something magical by feeding "git reset --hard" with ORIG_HEAD) might be just more noise and confusion. I can see them asking "why are there two ways to do identical things?".

However, the reason I am maintaining git is not to make it useful for _me_, but to make it useful for the kernel people, so if these BK-like synonyms help them, I'm all for it. If we are going to do that, somebody needs to describe what should each command do in each case in detail, because I do not know BK at all.

You guys were on BK for how many months, and have been on git for how many months now? Do BK-familiarity factor matter, and will it continue to matter for how long?

On Fri, 16 Dec 2005, Junio C Hamano wrote:

I don't think it is a huge deal, I suspect that people who used BK have a much easier time with git if only because they already understand the whole distributed thing and about commits and merges.

That said, I think a lot of newbies might want to have a "git undo", and not because of any BK history. Even if it just ends up being nothing but shorthand for "git reset --hard ORIG_HEAD".

		Linus

Linus Torvalds <torvalds@osdl.org> writes:

I agree to this in principle, but I am afraid "git undo" is too generic and fuzzy a term. Things you might possibly want to undo depends on what you did last [*1*]. In most undoable cases, "reset --hard" is almost right but most likely would result in information loss.

If we want to really newbie-proof the "undo" command, I think the hard ones are not the ones that can be approximated with reset ORIG_HEAD, but other "No way to undo" ones and "Nothing to undo" ones.

Earlier on the list I gave an overview on merge for an unnamed person with only an e-mail address, and one thing struck me as quite hard to explain was that there are two kinds of "merge failures" --- ones that did not even start the merge and ones that failed in the middle due to conflicts. Somebody totally new to git, after seeing "git pull" to fail in the first kind, would get scared and type "git undo". We could prevent doing damage by making sure we remove ORIG_HEAD in "Nothing to undo" situations, but if we say "Nothing to undo" when the user types "git undo" in such a situation, we will surely hear "what do you mean? the command said failed to pull and I wanted to recover from that!".

It also is not clear if it is wise to clear ORIG_HEAD for "No way to undo" ones. Doing so would rob useful undo information from people who know git and expect "No way to undo" ones do not muck with the existing ORIG_HEAD.

Even for the ones that we would do "reset --hard ORIG_HEAD", many lose information, and "undo" to me implies "undo only what the last command messed up", which is not what actually happens.

The word "reset" does not have that connotation -- it takes you to some defined state, which may be close to what you had before but may not be exactly the same if you had local changes in your tree. HEAD, ORIG_HEAD, and HEAD^ are such defined states you can go, and the user gives where he wants to go explicitly. "undo" does not really say where to go and hides halfway what we do, without doing exactly what the user would expect (and cannot be implemented fully unless we are willing to take a snapshot of working tree, I suspect).

[Appendix]

*1* List of commands that a user might want to undo.

A merge or non-merge commit, cherry-pick, and revert::
	reset --hard HEAD^ ;# this can be helped by leaving ORIG_HEAD
                            # but "--hard" is not quite right;
                            # your working tree could have been
                            # dirty at irrelevant paths

A fetch fast-forwarding non-current branch::
	No way to undo -- we do not keep the old information.

A merge, that was fast-forward::
	reset ORIG_HEAD ;# never "--hard" -- your working tree could
                         # have been dirty and in this case
                         # there is no information loss.

A merge attempt, conflicted::
	reset --hard ORIG_HEAD
                         # again, "--hard" is not quite right --
			 # your working tree could have been
                         # dirty at irrelevant paths.

A merge attempt, did not even start because index or tree was dirty::
	Nothing to undo.

A successful checkout (switch branch)::
	No way to undo -- we do not keep the old information.

git-update-index and git-add::
	No way to really undo -- we do not keep the old
	information.  The closest is "git reset" but it reverts
	more than the last operation.

rebase::
	reset --hard ORIG_HEAD

am/applymbox::
        No way to undo -- we do not keep the old information.
			;# this can be helped by leaving ORIG_HEAD

On Sat, 17 Dec 2005, Junio C Hamano wrote:

One observation is that ORIG_HEAD should probably be named PREV_HEAD in such context to make it more obvious what it is about.

Nicolas

Nicolas Pitre <nico@cam.org> writes:

I do not see much difference either way, but I suspect ORIG_HEAD is pretty much well established by now.

On Sat, 17 Dec 2005, Junio C Hamano wrote:

ORIG suggests "origin" to me, something that was there first, or before anything else. If you want to undo something, you want its "previous" state restored relative to the current state, not the absolute previous (first) one.

Well, cogito for one doesn't care at all, and it even doesn't make for it to be created/updated.

But still it can remain for what it is now, and PREV_HEAD added for undo purpose.

Not a big deal in any case though.

Nicolas

On Sat, 17 Dec 2005, Nicolas Pitre wrote:

It's meant to be short for ORIGinal, not ORIGin. That's how I wrote it and have always read it ;)

		Linus

Nicolas Pitre <nico@cam.org> writes:

Hmph.

I always thought it was original-head before the operation happened, which is why I said it is no different from previous-head.

On Sat, 17 Dec 2005, Junio C Hamano wrote:

OK I agree.

Nicolas

Morten Welinder <mwelinder@gmail.com> writes:

Yup. Maybe one line comment at the bottom of these manual pages pointing at git-reset manual page (which has nice examples section) would be good enough?

-- >8 -- [PATCH] Examples of resetting.

Morten Welinder says examples of resetting is really about recovering from botched commit/pulls. I agree that pointers from commands that cause a reset to be needed in the first place would be very helpful.

Also reset examples did not mention "pull/merge" cases.

Signed-off-by: Junio C Hamano <junkio@cox.net>
---