Re: [PATCH v2] Fix fetch/pull when run without --update-head-ok

On Tue, 14 Oct 2008, Johannes Schindelin wrote:

Hi,

On Tue, 14 Oct 2008, Daniel Barkalow wrote:

quoted

On Tue, 14 Oct 2008, Johannes Schindelin wrote:

quoted

On Mon, 13 Oct 2008, Daniel Barkalow wrote:

quoted

On Mon, 13 Oct 2008, Johannes Schindelin wrote:

quoted

I actually understand now why the tests started failing: the 
change from resolve_ref() to get_branch() as requested by Daniel 
are at fault: get_branch() does not check if the branch has an 
initial commit.

I am actually regretting making this change.  Daniel, do you agree 
that it might be better to change back to resolve_ref(), so that 
the initial complaint (IIRC Han-Wen git pull'ed into a freshly 
initialized repository with that utterly bogus "git pull origin 
master:master" line) is not re-raised?

Is it, in fact, okay to fetch into the current branch if it's "yet 
to be born"? I feel like it shouldn't be, since you'll get exactly 
the same problem that you would if the branch already existed: the 
index reflects the previous state (in this case, it's empty), so git 
will show that you've staged removing all of the files, right? So 
this would make the check for --update-head-ok more strict than 
before, but I think the behavior change is correct.

I think 
http://thread.gmane.org/gmane.comp.version-control.git/31351/focus=31544 
is the best link to see what Han-Wen said.  Granted, it was a 
misunderstanding on his part, but there have been quite a few people 
with the same misunderstanding.

So what they did was

	$ mkdir just-one-branch
	$ cd just-one-branch
	$ git init
	$ git remote add origin <url>
	$ git pull origin master:master

And this _will_ work correctly.  Except when using get_branch(NULL) 
instead of the validating resolve_ref().

"git pull origin master:master" invokes "git fetch" with --update-head-ok, 

Does it?  You're correct.  I do not like it.

The reason that it runs with --update-head-ok (and the reason that 
--update-head-ok exists in the first place) is that, when you're doing a 
pull, if you fetch into the current branch, pull will identify that you've 
actually fast-forwarded the current branch and will update the working 
tree and index accordingly (which it's allowed to do because it's expected 
to perform a merge in the working tree and index).

That is, it uses --update-head-ok because "git pull origin master:master" 
will work correctly, regardless of whether the local master is 
yet-to-be-born or not.

	-Daniel
*This .sig left intentionally blank*