Ramkumar Ramachandra <artagnon@xxxxxxxxx> writes: > Finds symbolic names suitable for human digestion for revisions > given in any format parsable by git rev-parse. > > It is meant to name _revisions_ (aka. commits): That is a mistaken documentation, written based on a half-baked implementation that conflated "the current code only can handle commits" with "we need to only handle commit and nothing, ever". We had to fix a similar misguided/short-sighted implementation in the "git fetch" codepath when adding "git pull/merge $tag" (the code peeled a tag object too early when writing FETCH_HEAD out, losing information if what we were given was a tag or a commit). I do not want to see us making the mistake worse unnecessarily. When we see a commit object that is pointed by tag v1.8.3, it is the right thing to do to return v1.8.3^0 as its string representation so that "git rev-parse v1.8.3^0" give us the same thing back. name-rev that is fed a tag object v1.8.3 should give v1.8.3 (not v1.8.3^0) back, otherwise feeding its output to "git rev-parse" will not give us the same thing we fed as the input to name-rev. -- 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