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

[Jeff King <peff@peff.net>]

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

> > I disagree. If I do:
> >
> >  git foo 2>errors
> >
> > I would certainly expect any relevant errors to end up in that file. As
> > for why I would do that, two cases I can think of offhand are:
> >
> >  1. Test scripts, which use this extensively.
> >
> >  2. Sometimes cron jobs will capture chatty output in a file and show
> >     it only in the case of some error condition.
> >
> 
> 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).

Obviously this is a pretty trivial example that I cooked up for this
email. But the concept of stash-stderr-and-report-on-error is a pretty
common pattern for cron jobs.

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

-Peff