[PATCH 0/9] Extending the shelf life of "git describe" output

[Junio C Hamano <gitster@pobox.com>]

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