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

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

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

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