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

From: Daniel Barkalow <barkalow@iabervon.org>
Date: Oct 14, 2008, 16:52 UTC
Message-ID: <alpine.LNX.1.00.0810141240510.19665@iabervon.org>
In-Reply-To: <alpine.DEB.1.00.0810141815490.22125@pacific.mpi-cbg.de.mpi-cbg.de>

On Tue, 14 Oct 2008, Johannes Schindelin wrote:

Show 49 quoted lines

> Hi,
> 
> On Tue, 14 Oct 2008, Daniel Barkalow wrote:
> 
> > On Tue, 14 Oct 2008, Johannes Schindelin wrote:
> > 
> > > On Mon, 13 Oct 2008, Daniel Barkalow wrote:
> > > 
> > > > On Mon, 13 Oct 2008, Johannes Schindelin wrote:
> > > > 
> > > > > 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*