From: Junio C Hamano <gitster@pobox.com>
Date: Wed, 04 Jul 2007 16:58:03 GMT
Subject: Re: [PATCH] gitk: fix for "gitk <ambiguous-name> --"
Message-ID: <7v1wfohzs4.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <18059.31237.286280.566140@cargo.ozlabs.ibm.com>

Paul Mackerras <paulus@samba.org> writes:

> Junio: there seems to be an inconsistency between git rev-list and git
> rev-parse here.  If a name is both a filename and a ref, git rev-list
> will give a fatal error but git rev-parse will take it as a ref.

	$ rev-parse --no-revs --no-flags gitk -- gitk
	$ rev-parse --no-revs --no-flags -- gitk

should give you the path "gitk", while

	$ rev-parse --revs-only --no-flags gitk -- gitk
	$ rev-parse --revs-only --no-flags gitk --

should give you the revision (i.e. branch name) "gitk", I think.

But it is not well defined what it should do upon

	$ rev-parse --no-flags gitk
	$ rev-parse gitk

Currently they treat "gitk" as a ref.  On the other hand, as you
said:

	$ rev-list gitk

would error out without leading or traiing -- to disambiguate.

So you are right that they behave differently.

It might be an improvement to make rev-parse require leading or
trailing -- in such a case, but I haven't thought through the
ramifications of such a change.  Quite a lot of existing users
expect "rev-parse foo" to favor a ref "foo" over a file "foo"
and give its object name.