Hi, 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(). When we talk about not breaking existing behavior, we have to talk about this behavior, too. So, my vote is to revert back to resolve_ref(), even if it needs more lines. Thoughts of others? Ciao, Dscho -- 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
