On Mon, May 9, 2011 at 12:32 PM, Jeff King <peff@xxxxxxxx> wrote: > On Mon, May 09, 2011 at 10:41:02AM +0200, Erik Faye-Lund wrote: >> I was talking about warnings, not errors. But I can also see that one >> would sometimes want warnings even when not connected to a tty, but >> perhaps only when -v is specified? > > I know. I meant a script like this: > > cat >>foo.sh <<'EOF' > # go to branch in question > git checkout "$1" > > # note some point of interest > sha1=`git rev-parse "$2"` > > # do some script-specific inspection of $sha1, and > # merge if it looks OK > if test -z "$(git log ..$sha1 -- some-path)"; then > git merge $sha1 || exit 1 > fi > EOF > > It may produce some chatty output (like "switched to branch..."). So I > redirect it to a file, and if everything is successful, that output is > uninteresting. But if it fails, then I want to see everything. So I do > something like: > > if ! foo.sh master topic >output.tmp 2>&1; then > cat output.tmp > exit 1 > fi > > If the merge fails, it will produce an error message. But I _also_ want > to see any warnings that were generated by it and earlier commands, like > rev-parse (e.g., an ambiguous ref warning might help us understand why > the merge failed). 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. But I have no strong feelings about this, so it's probably better to leave it alone. >> > Yeah, if we disambiguate, I would be tempted to say that "HEAD" always >> > unambiguously refers to "HEAD". >> >> While that would touch less code, my gut tells me it's a bit more >> fragile. But perhaps you're right; I can't come up with any real >> arguments (i.e use cases that I care about) on top of my head. > > Honestly, I'm kind of surprised it's not that way already. It would make > sense to me that "upper" levels would take precedence over lower levels, > but that ambiguity would occur within a level. So if I say "foo", we > would look for: > > 1. $GIT_DIR/foo, with no ambiguity > > 2. $GIT_DIR/refs/foo, with no ambiguity > > 3. $GIT_DIR/refs/tags/foo > $GIT_DIR/refs/heads/foo > $GIT_DIR/refs/remotes/foo > > And note any ambiguity between those three. > > Which is not very different than what we do today, except that things > like HEAD and FETCH_HEAD would always be unambiguously about the > top-level. > I think that would make sense. >> > And "refs/HEAD" should already work, no? >> >> No: >> $ git init foo >> $ cd foo/ >> $ echo "foo" > bar >> $ git add bar >> $ git commit -m. >> [master (root-commit) fc0cbef] . >> warning: LF will be replaced by CRLF in bar. >> The file will have its original line endings in your working directory. >> 1 files changed, 1 insertions(+), 0 deletions(-) >> create mode 100644 bar >> $ git show refs/HEAD >> fatal: ambiguous argument 'refs/HEAD': unknown revision or path not in >> the working tree. >> Use '--' to separate paths from revisions > > 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. > What I failed to notice is that the likely disambiguator is actually > "refs/heads/HEAD" if you erroneously made a branch. > > Try this: > > # A repo with two commits > git init repo && cd repo && > echo content >file && > git add file && > git commit -m one && > echo content >>file && > git commit -a -m two && > > # And an ambiguously named ref called HEAD, pointing to "one"; > # our real HEAD is still pointing to "two" > git branch HEAD HEAD^ && > > # This should warn of ambiguity, but show "two" > git log -1 --oneline HEAD > > # And this should not be ambiguous at all, and show "one" > git log -1 --oneline refs/heads/HEAD > > # You can even do the same thing with refs/HEAD if you want, but > # you have to use plumbing to get such a ref. > git branch -d HEAD > git update-ref refs/HEAD HEAD^ > > # same as before, ambiguous "two" > git log -1 --oneline HEAD > > # or we can use refs/HEAD to get "one" > git log -1 --oneline refs/HEAD > > So most of that makes sense to me. We choose $GIT_DIR/HEAD over other > options, and you can specifically refer to something further down by > its fully-qualified name. > > The only thing that I think we might want to change is that "HEAD" is > considered ambiguous with "refs/heads/HEAD". On the other hand, it seems > a little insane to name your branch that, given that it has a > well-established meaning in git. 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. > 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. 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. -- 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