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. -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
