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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 14 Oct 2008, Daniel Barkalow wrote:

> On Tue, 14 Oct 2008, Johannes Schindelin wrote:
> 
> > 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.

In particular, the --update-head-ok is from b10ac50f, which is what added 
the check to prohibit fetching into the current branch otherwise, back in 
August 2005. There's never been anything preventing updating the current 
branch using "pull".

	-Daniel
*This .sig left intentionally blank*
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux