Junio C Hamano wrote: > But I do not think "name-rev" is limited > to commits, in the sense that you would see this: > > $ git rev-parse v1.8.3 v1.8.3^0 | git name-rev --stdin > 8af06057d0c31a24e8737ae846ac2e116e8bafb9 > edca4152560522a431a51fc0a06147fc680b5b18 (tags/v1.8.3^0) > > The second object is _not_ v1.8.3 but is v1.8.3^0 in the context of > name-rev, whose purpose is to give you a string you can feed > "rev-parse" and get the object name back. "rev-parse v1.8.3" will > not give you the commit object name, so you need to keep "^0". Quite frankly, I thought the unstripped ^0 in one codepath was an unintended quirk. What exactly do you want name-rev to give you? $ git tag foo @^ $ git name-rev foo foo tags/foo So you can distinguish between annotated tags, unannotated tags, and head-refs. Can you get it to tell you anything reliably though? $ git tag bar @ $ git tag -a baz @ $ git name-rev @ $ git name-rev bar $ git name-rev baz ref, annotated, or unannotated tag? I do not think name-rev is fundamentally different from describe: it is also only dependent on the commit history graph. Whether I specify a revision using @, HEAD, baz, or bar, I should get the same answer (it's just a recursive peeler). I'm not sure what you gain by knowing the object type of the output. If you wanted to feed something into rev-parse and get out a commit, you'd send in $REV^0 without bothering about what it is, no? -- 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