Paul Mackerras <paulus@xxxxxxxxx> 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. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
