Re: [RFC/PATCH] Detailed diagnostic when parsing an object name fails.

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 30, 2009, 20:12 UTC
Message-ID: <7vtywbkc05.fsf@alter.siamese.dyndns.org>
In-Reply-To: <1259603421-10055-1-git-send-email-Matthieu.Moy@imag.fr>

Matthieu Moy <Matthieu.Moy@imag.fr> writes:

Show 10 quoted lines

> The original motivation is actually to anwser the FAQ of "git show
> HEAD:foo.txt" being relative to the root, while some users would
> expect it relative to $PWD but the patch ended up being far more
> general. At least, 
>
> $ cd git
> $ cd t
> $ ../git show HEAD:test-lib.sh 
> fatal: Path 't/test-lib.sh' exists, but not 'test-lib.sh'.
> Did you mean 'HEAD:t/test-lib.sh'?

The first thought that comes to mind is that if it makes more sense to just fall back to the interpretation of the input when the tool has already figured out to second guess the intention of the user like the above message does.

That would obviously break scripts that try to make sure the _absense_ of a path in a tree-ish (or in the index if you lack "HEAD" in your example), expecting:

   git rev-parse HEAD:test-lib.sh ||
   echo "test-lib.sh shouldn't be at the top level"

to work regardless of where you are in the work tree, so it won't fly well.

Perhaps the second step would be to teach the machinery to understand a syntax like "<tree-ish>:./<path>" and have it prefix the path to the current subdirectory from the root of the work tree, and with such an enhancement, the suggestion given by this patch would probably change to "Did you mean 'HEAD:./test-lib.sh'?", but that would be a separate topic.