On Tue, Aug 27, 2013 at 12:07 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > 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), "My #1" is really "what I inferred from your statements." I did not think the tuple was important, but I agree that may be my shortsightedness. If the tuple is important, then it seems to me that the --null behavior is a bug (the colon is left intact); but changing it now seems senseless or harmful. > 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. I am beginning to agree, though we discovered some other weird output from grep which also does not parse. (origin/master:../relative/path). It seems that fixing this bug could be very confusing for get_sha1_with_context unless the context was rewritten to match the traditional syntax. P -- 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