The output from "git describe" is a tagname, dash, number, dash, and 'g' followed by an abbreviated commit object name, and it can be used anywhere we expect an object name. This is so that people can use it to name an exact commit in the inter-human communication. The recipients are expected to be able to cut & paste it to their command line. Because it uses an abbreviated commit object name, it is possible that a "git describe" name taken earlier can become ambiguous over time, even though "git describe" ensures the uniqueness of its output in the repository when it runs. This series teaches the sha1_name machinery to only look for unambigous commit object names when the caller knows that the name must refer to a commit object. By taking advantage of the fact that there are more trees and blobs in a project's history than commits by definition, this reduces the potential of collisions, extending the shelf life of "git describe" output by a little bit. Building on the foundation this series lays, I can see two separate avenues to further extend this work: - You will further be able to extend the lifetime of uniqueness of "git describe" output if you take advantage of the "tagname" or "number". The current parser does not do this. There are a number of ways to do this, but probably the cleanest would be to (you only can do this when you have "tagname" tag locally; you may not have it) pass the tag and the number down to the find_short_*() routines with commit_only set, and when they find a commit that match the prefix, inside is_commit_object() test, check also that the commit reaches the given tag object in the given number steps (otherwise discard it as it is not the one you are looking for). - Some callers that are involved in the get_sha1_1() callpath know that the name they have must be referring to commit objects (e.g. get_parent() and get_nth_ancestor()). It might be worthwhile to let get_sha1_1() know that the caller knows the name it is feeding must refer to a commit object, and have the uniqueness logic take advantage of it. I think that most of these callers are expecting to parse a committish and the user may have given them the name of a a tag object that peels to a commit, so you would need to add a new GET_SHORT_COMMITTISH that allows any committish, in addition to the GET_SHORT_COMMIT_ONLY this series adds, if you want to do this. I do not claim the ownership rights on either of the above ideas; people who find them interesting are welcome to pursue them (hint, hint). Junio C Hamano (9): sha1_name.c: indentation fix sha1_name.c: clarify what "fake" is for in find_short_object_filename() sha1_name.c: rename "now" to "current" sha1_name.c: refactor find_short_packed_object() sha1_name.c: teach find_short_object_filename() a commit-only option sha1_name.c: teach find_short_packed_object() a commit-only option sha1_name.c: allow get_short_sha1() to take other flags sha1_name.c: teach get_short_sha1() a commit-only option sha1_name.c: get_describe_name() by definition groks only commits sha1_name.c | 157 ++++++++++++++++++++++++++++++++++++++---------------------- 1 file changed, 101 insertions(+), 56 deletions(-) -- 1.7.11 -- 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