Re: [RFC] pull/fetch rename

On 2009.10.21 00:22:18 -0400, Daniel Barkalow wrote:

On Wed, 21 Oct 2009, Björn Steinbrink wrote:

quoted

3) User expects "pull" to update all branch heads that have a configured
upstream

08:31 	dimsuz 	hi guys! suppose i'm currently on master. then run git
		fetch. which delivers updates to master and other
		branches. I don't merge anything, but do checkout some
		branch (which is not master).  Question: will these new
		updates get into this branch automatically after i check
		it out? question2: will branch master contain those
		updates when i ckeck it out later?
08:32 	Circuitsoft 	dimsuz. After a fetch, no.
08:33 	Circuitsoft 	However, if you pull, any branches that were set
			up as local tracking branches will get updated.
08:33 	Circuitsoft 	Otherwise, only remote tracking branches will be
			updated.

http://colabti.de/irclogger/irclogger_log/git?date=2009-10-20#l969
(No idea about that one, have seen that once before, but it's definitely
not even remotely as common as the others)

I'd guess that's due to having local branches with no local changes, just 
to avoid detached HEAD, and therefore thinking it's normal to have a bunch 
of local branches that could be updated without merges. But I'm on a crazy 
"everybody really wants detached HEAD and is needlessly scared" kick, and 
I'm probably reading too much into it.

Just to clarify: I didn't mean the question (which I didn't really
understand) in this case, but the answer from Circuitsoft (second to
last line). But maybe you also meant that? The question confuses me
enough not to be able to follow.

quoted

4) User expects "pull" to create branches

07:25 	fynn 	Hey, I just pulled a branch from remote, and I don't see
		it in "git branch"
07:25 	doener 	fynn: if you "pull" that means "fetch this and merge it
		to what I have checked out"
07:25 	fynn 	doener: hm, I just did "git pull" and it showed the new
		branch
07:26 	fynn 	but I don't see it in my branches...
07:26 	fynn 	doener: should I create that branch as a tracking branch
		first?
07:26 	doener 	fynn: you're looking at "git branch -r" or "git branch
		-a", right?
07:26 	fynn 	doener: yeah, I'm seeing it in origin/foo, but not
		local.
07:26 	doener 	fynn: the "git fetch" should have created a remote
		tracking branch, as usual, not a local branch head
		(which would be shown by just "git branch")
07:27 	fynn 	doener: OK, what should I do to create it locally then?
07:28 	doener 	fynn: just the usual "git branch foo origin/foo", or to
		checkout at the same time: "git checkout -b foo
		origin/foo" or "git checkout -t origin/foo" (shortcut)

http://colabti.de/irclogger/irclogger_log/git?date=2009-10-19#l830
(Note how my "fetch this and merge it" is actually inaccurate for just
"git pull", there is no "this" and that case. I took "pulled a branch"
to mean that he did "git pull <remote> <branch>", which wouldn't have
created/update the remote tracking branch [or did patches for that go
in? I lost track...])

That sounds like a real converse of "push", including creating like-named 
local branches. Or, perhaps, this is someone expecting that "pull" is like 
"clone" in creating an initial local branch with the name and value of a 
specified remote branch.

Reading that one again, I realize that I've still been confused by the
"pulled a branch". What happened was that the user did "git pull", which
ran "git fetch <remote>", which fetched a new branch head and has shown
that. At that point, the user (and me) got confused for maybe two reasons:

a) He didn't clearly distinguish between the fetch and the merge part.
The new branch wasn't pulled, but just fetched. That caused the user to
think that he "pulled the branch" (wrong terminology), which in term
confused me (wrong use-case assumed).

b) He expected local branch heads to be created, instead of remote
tracking branches. If my memory doesn't play tricks on me, that's
actually not to be expected from that specific user (I think we told him
about remote tracking branches before, and the last part of the
conversation actually suggests that, too). If I don't forget, I'll try
to get feedback from him the next time he's around.

quoted

5) User possibly expecting "pull" to be able to act as "reset --hard"

21:01 	aidan 	What do I do about this: html/config/core.php: needs
		update
21:02 	aidan 	git pull (gives that)
21:02 	Ilari 	aidan: You have uncommitted changes to that file...
21:15 	aidan 	Ilari: how can I just pull master and overwrite any
		changes?

http://colabti.de/irclogger/irclogger_log/git?date=2009-10-18#l2130
(I'm not sure about that one, "overwrite any changes" might mean "drop
uncommitted changes and merge" or "just get me the remote's state,
dropping my commits and uncommitted changes". Most of the time I've seen
similar requests, the user wanted the latter).

So I think that's a desire for "git checkout ." first of all (with the 
assumption that the content without modifications has to come from 
somewhere remote). I don't know what's up with people not wanting to save 
their commits, though.

You haven't seen the multitude of "I have merge conflicts and just want
to take theirs/mine" requests. That often gets more weird than just
"drop my commits" ;-)

quoted

6) User says "pull" but probably means "fetch"

14:08 	Alien_Freak 	once I have a clone of a repo I know you can do
			a checkout tag but is there anyway to pull just
			the tag?

http://colabti.de/irclogger/irclogger_log/git?date=2009-10-16#l1664
(There was no answer, thus it's hard to tell, but I guess he wanted
something like:
git init; git fetch --no-tags url tag <tag>; git checkout <tag>
At least I'm quite sure he didn't mean "pull" as in "git pull")

I don't know; you can actually do:

$ git init; git pull --no-tags <url> tag <tag>

It updates the master branch and working directory from (nothing) to the 
fetched tag.

Hm, yeah, that works (didn't think of it), but it's a rather special
case. Teaching that might lead to misunderstandings about what "pull"
does, I think. It would look somewhat like "fetch + reset --hard".

quoted

8) "reset --hard" again

20:10 	roger_padactor 	i commited then did a pull how do i get back to
			my commit. the pull over wrote the files
20:11 	merlin83 	roger_padactor: you can't, pull == fetch + hard
			reset to latest commit

http://colabti.de/irclogger/irclogger_log/git?date=2009-10-14#l2306
(Someone being told that pull is fetch + reset --hard is actually new to
me. Only saw that as an expectation previously.)

That's odd. How could you not notice that it doesn't actually do that, 
even if you try to get it to?

Hm? roger_padactor noticed that "pull" changed his files and wants to go
back. And merlin83 says that that is impossible because pull supposedly
does reset --hard. There's nothing in there (I could see) that suggests
that anyone tried to make "pull" do "reset --hard".

merlin83 basically made three mistakes, I think:
1) Assume that roger_padactor was talking about uncommitted changes
2) Assume that pull is fetch + reset --hard
3) Assume that you can't undo a reset --hard for committed changes

(OK, 3) isn't actually valid when you consider 1), but 1) is so invalid
that I kept 3). After all, "pull" would complain about a dirty tree...)

Actually, I wonder if the right formula is update = fetch + checkout. 
There are a lot of people (IMHO) want "git fetch origin; git checkout 
origin/master", and I think their first idea is "git update", but that 
doesn't exist, and they find "pull" as the closest thing.

That has a precondition that the user is already using a detached HEAD.
Otherwise that fetch + checkout would likely mean that the get baffled
when they do:
git checkout master
git update
git checkout foo
git checkout master

Seeing that "master" is out of date "again".

I agree though, that users might look for "git update" and because it is
missing, they just look for the closest thing. Adding Junio's statement
that users seem to want recipes instead of flexibility (and seeing
"update" as just "get me new stuff from upstream" without meaning any
specific method of updating), I think that "git update" could be a "recipe
collection" tool. I'll hack that into my proof-of-concept thing (which
I hope to have ready for a RFC next week).

Björn