Paul Mackerras <paulus@samba.org> writes:

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



-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html