Re: [PATCH] only warn about ambiguous refs if stderr is a tty

On Mon, May 9, 2011 at 12:32 PM, Jeff King [off-list ref] wrote:

On Mon, May 09, 2011 at 10:41:02AM +0200, Erik Faye-Lund wrote:

quoted

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.

quoted

quoted

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.

quoted

quoted

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.