On Mon, May 09, 2011 at 02:37:48PM +0200, Erik Faye-Lund wrote: > Yeah, I understood that part. My point was that once the output is > wanted for diagnostics, you probably also want verbose output. And > warnings should probably always be output if we're verbose. Ah, I see. I think my main concern is that the behavior you proposed would simply be surprising to people used to normal unix conventions. But it sounds like we both agree that isn't the right direction anyway. > > Of course, because there is no refs/HEAD at all. I meant "if you have > > ambiguity between $GIT_DIR/HEAD and $GIT_DIR/refs/HEAD", then saying > > "refs/HEAD" should disambiguate already. In your example, there is no > > ambiguity. > > I meant that "refs/HEAD" could be an non-ambiguous alias for HEAD, but > it's probably easier to just say that 'HEAD' isn't ambiguous. Your > suggestion of only checking for ambiguousness on the same level is IMO > an elegant way of doing this. OK, I see what you meant. But "refs/HEAD" cannot be a shortcut for "HEAD", as it means something totally different. You can have "HEAD", "refs/HEAD", "refs/heads/HEAD" all co-existing. > I agree. There could be a remote chance that you can get a branch > called 'HEAD' from some foreign vcs or something, though. But I don't > think it's very likely, and the problem will also go away if we go > with your approach mentioned above. Thinking on it more, I think warning is probably the only sane thing to do there. Having a branch with that name is just going to be confusing in the long run, and the sooner we start making the user aware of the situation, the better. > > I admit I haven't been following this > > thread too closely. What is the reason not to tell the user "sorry, that > > is an insane branch name. Accept the ambiguity warning, or choose a > > different name"? > > I think having the ambiguity warning in itself isn't the problem, it's > gitk not swallowing it that is. Agreed. > The reporter also had some problems pushing with a branch named 'HEAD' > in his repo, but I didn't look into that part at all. I expect that would be a separate issue entirely (if it were fetching, I wouldn't be surprised if it was the "fake" refs/remotes/*/HEAD symref we create getting in the way). -Peff -- 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