Junio C Hamano <gitster@xxxxxxxxx> writes: > Not necessarily. If the user is asking the question in a more > natural way (I want to see where in 'next' branch's tip commit hits > appear, by the way, I know I am only interested in builtin/ so I'd > give pathspec as well when I am asking this question), the output > does give <commit> <colon> <path>, so it is more than coincidence. This part needs to be qualified. "Natural" is of course in the eyes of beholder. If we assume that your #1 holds true (i.e. the tuple <in which tree object are we reporting, what path we saw hits> is important and merging them into one <in what blob we saw hits> lose information), then it is natural to ask "inside origin/master tree, where do I have hits? By the way, I am only interested in builtin/" and get "origin/master:builtin/pack-objects.c" as an answer (this is from your earlier example), than asking "inside origin/master:builtin tree, where do I have hits?" If we do not consider #1 is false and the tree information can be discarded, then it does not matter if we converted the colon after origin/master to slash when we answer the latter question, and the latter question stops being unnatural. > ... > but it might be a good change to allow A:B:C to be parsed as a > proper extended SHA-1 expression and make it yield > > git rev-parse $(git rev-parse $(git rev-parse A):B):C > > Right now, "B:C" is used as a path inside tree-ish "A", but I think > we can safely fall back, when path B:C does not appear in tree-ish > A, to see if path B appears in it and is a tree, and then turn it > into a look-up of path C in that tree A:B. And if we want to keep the <tree, path> tuple, but still want to make it easier to work with the output, allowing A:B:C to be parsed as an extended SHA-1 expression would be a reasonable solution, not a work-around. The answer is given to the question asked in either way (either "in origin/master, but limited to these pathspecs" or "in the tree origin/master:builtin/") without losing information, but the issue you had is that the answer to the latter form of question is not understood by the object name parser, which I personally think is a bug. -- 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