Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Commits on Feb 28, 2008
  1. @spearce @gitster

    Teach git-describe to verify annotated tag names before output

    spearce authored gitster committed
    If an annotated tag describes a commit we want to favor the name
    listed in the body of the tag, rather than whatever name it has
    been stored under locally.  By doing so it is easier to converse
    about tags with others, even if the tags happen to be fetched to
    a different name than it was given by its creator.
    
    To avoid confusion when a tag is stored under a different name
    (and thus is not readable via git-rev-parse --verify, etc.) we show
    a warning message if the name of the tag does not match the ref
    we found it under and if that tag was also selected for output.
    For example:
    
      $ git tag -a -m "i am a test" testtag
      $ mv .git/refs/tags/testtag .git/refs/tags/bobbytag
    
      $ ./git-describe HEAD
      warning: tag 'testtag' is really 'bobbytag' here
      testtag
    
      $ git tag -d testtag
      error: tag 'testtag' not found.
      $ git tag -d bobbytag
      Deleted tag 'bobbytag'
    
    Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commits on Feb 24, 2008
  1. @spearce @gitster

    Teach git-describe --exact-match to avoid expensive tag searches

    spearce authored gitster committed
    Sometimes scripts want (or need) the annotated tag name that exactly
    matches a specific commit, or no tag at all.  In such cases it can be
    difficult to determine if the output of `git describe $commit` is a
    real tag name or a tag+abbreviated commit.  A common idiom is to run
    git-describe twice:
    
      if test $(git describe $commit) = $(git describe --abbrev=0 $commit)
      ...
    
    but this is a huge waste of time if the caller is just going to pick a
    different method to describe $commit or abort because it is not exactly
    an annotated tag.
    
    Setting the maximum number of candidates to 0 allows the caller to ask
    for only a tag that directly points at the supplied commit, or to have
    git-describe abort if no such item exists.
    
    Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
  2. @spearce @gitster

    Avoid accessing non-tag refs in git-describe unless --all is requested

    spearce authored gitster committed
    If we aren't going to use a ref there is no reason for us to open
    its object from the object database.  This avoids opening any of
    the head commits reachable from refs/heads/ unless they are also
    reachable through the commit we have been asked to describe and
    we need to walk through it to find a tag.
    
    Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
  3. @spearce @gitster

    Teach git-describe to use peeled ref information when scanning tags

    spearce authored gitster committed
    By using the peeled ref information inside of the packed-refs file we
    can avoid opening tag objects to obtain the commits they reference.
    This speeds up git-describe when there are a large number of tags
    in the repository as we have less objects to parse before we can
    start commit matching.
    
    Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commits on May 22, 2007
  1. @spearce

    Teach git-describe how to run name-rev

    spearce authored Junio C Hamano committed
    Often users want to know not which tagged version a commit came
    after, but which tagged version a commit is contained within.
    This latter task is the job of git-name-rev, but most users are
    looking to git-describe to do the job.
    
    Junio suggested we make `git describe --contains` run the correct
    tool, `git name-rev`, and that's exactly what we do here.  The output
    of name-rev was adjusted slightly through the new --name-only option,
    allowing describe to execv into name-rev and maintain its current
    output format.
    
    Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
    Signed-off-by: Junio C Hamano <junkio@cox.net>
Commits on Jan 28, 2007
  1. @spearce

    Compute accurate distances in git-describe before output.

    spearce authored Junio C Hamano committed
    My prior change to git-describe attempts to print the distance
    between the input commit and the best matching tag, but this distance
    was usually only an estimate as we always aborted revision walking
    as soon as we overflowed the configured limit on the number of
    possible tags (as set by --candidates).
    
    Displaying an estimated distance is not very useful and can just be
    downright confusing.  Most users (heck, most Git developers) don't
    immediately understand why this distance differs from the output
    of common tools such as `git rev-list | wc -l`.  Even worse, the
    estimated distance could change in the future (including decreasing
    despite no rebase occuring) if we find more possible tags earlier
    on during traversal.  (This could happen if more tags are merged
    into the branch between queries.)  These factors basically make an
    estimated distance useless.
    
    Fortunately we are usually most of the way through an accurate
    distance computation by the time we abort (due to reaching the
    current --candidates limit).  This means we can simply finish
    counting out the revisions still in our commit queue to present
    the accurate distance at the end.  The number of commits remaining
    in the commit queue is probably less than the number of commits
    already traversed, so finishing out the count is not likely to take
    very long.  This final distance will then always match the output of
    `git rev-list | wc -l`.
    
    We can easily reduce the total number of commits that need to be
    walked at the end by stopping as soon as all of the commits in the
    commit queue are flagged as being merged into the already selected
    best possible tag.  If that's true then there are no remaining
    unseen commits which can contribute to our best possible tag's
    depth counter, so further traversal is useless.
    
    Basic testing on my Mac OS X system shows there is no noticable
    performance difference between this accurate distance counting
    version of git-describe and the prior version of git-describe,
    at least when run on git.git.
    
    Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
    Signed-off-by: Junio C Hamano <junkio@cox.net>
  2. @spearce

    Teach git-describe to display distances from tags.

    spearce authored Junio C Hamano committed
    If you get two different describes at different
    times from a non-rewinding branch and they both come up with the same
    tag name, you can tell which is the 'newer' one by distance.  This is
    rather common in practice, so its incredibly useful.
    
    [jc: still needs documentation and fixups when traversal gives up
     early.]
    
    Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
    Signed-off-by: Junio C Hamano <junkio@cox.net>
Commits on Jan 26, 2007
  1. @spearce

    Remove unnecessary found variable from describe.

    spearce authored Junio C Hamano committed
    Junio added the found variable to enforce commit date order when two
    tags have the same distance from the requested commit.  Except it is
    unnecessary as match_cnt is already used to record how many possible
    tags have been identified thus far.
    
    Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
    Signed-off-by: Junio C Hamano <junkio@cox.net>
Commits on Jan 15, 2007
  1. @spearce

    Remove hash in git-describe in favor of util slot.

    spearce authored Junio C Hamano committed
    Currently we don't use the util field of struct commit but we want
    fast access to the highest priority name that references any given
    commit object during our matching loop.  A really simple approach
    is to just store the name directly in the util field.
    
    Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
    Signed-off-by: Junio C Hamano <junkio@cox.net>
  2. @spearce

    Correct priority of lightweight tags in git-describe.

    spearce authored Junio C Hamano committed
    We really want to always favor an annotated tag over a lightweight
    tag when describing a commit.  Unfortunately git-describe wasn't
    doing this as it was favoring the depth attribute of a possible_tag
    over the priority.  Now priority is the highest sort and we only
    consider a lightweight tag if no annotated tags were identified.
    
    Rather than searching for the minimum tag using a simple loop we
    now sort them using a stable sort algorithm, this way the possible
    tags display in order if --debug gets used.  The stable sort helps
    to preseve the inherit topology/date order that we obtain during
    our search loop.
    
    This fix allows the tests in t6120-describe.sh to pass.
    
    Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
    Signed-off-by: Junio C Hamano <junkio@cox.net>
  3. @spearce

    Improve git-describe performance by reducing revision listing.

    spearce authored Junio C Hamano committed
    My prior version of git-describe ran very slowly on even reasonably
    sized projects like git.git and linux.git as it tended to identify
    a large number of possible tags and then needed to generate the
    revision list for each of those tags to sort them and select the
    best tag to describe the input commit.
    
    All we really need is the number of commits in the input revision
    which are not in the tag.  We can generate these counts during
    the revision walking and tag matching loop by assigning a color to
    each tag and coloring the commits as we walk them.  This limits us
    to identifying no more than 26 possible tags, as there is limited
    space available within the flags field of struct commit.
    
    The limitation of 26 possible tags is hopefully not going to be a
    problem in real usage, as most projects won't create 26 maintenance
    releases and merge them back into a development trunk after the
    development trunk was tagged with a release candidate tag.  If that
    does occur git-describe will start to revert to its old behavior of
    using the newer maintenance release tag to describe the development
    trunk, rather than the development trunk's own tag.  The suggested
    workaround would be to retag the development trunk's tip.
    
    However since even 26 possible tags can take a while to generate a
    description for on some projects I'm defaulting the limit to 10 but
    offering the user --candidates to increase the number of possible
    matches if they need a more accurate result.  I specifically chose
    10 for the default as it seems unlikely projects will have more
    than 10 maintenance releases merged into a development trunk before
    retagging the development trunk, and it seems to perform about the
    same on linux.git as v1.4.4.4 git-describe.
    
    A large amount of debugging information was also added during
    the development of this change, so I've left it in to be toggled
    on with --debug.  It may be useful to the end user to help them
    understand why git-describe took one particular tag over another.
    
    Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
    Signed-off-by: Junio C Hamano <junkio@cox.net>
  4. @spearce

    Use binary searching on large buckets in git-describe.

    spearce authored Junio C Hamano committed
    If a project has a really huge number of tags (such as several
    thousand tags) then we are likely to have nearly a hundred tags in
    some buckets.  Scanning those buckets as linked lists could take
    a large amount of time if done repeatedly during history traversal.
    
    Since we are searching for a unique commit SHA1 we can sort all
    tags by commit SHA1 and perform a binary search within the bucket.
    Once we identify a particular tag as matching this commit we walk
    backwards within the bucket matches to make sure we pick up the
    highest priority tag for that commit, as the binary search may
    have landed us in the middle of a set of tags which point at the
    same commit.
    
    Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
    Signed-off-by: Junio C Hamano <junkio@cox.net>
  5. @spearce

    Hash tags by commit SHA1 in git-describe.

    spearce authored Junio C Hamano committed
    If a project has a very large number of tags then git-describe
    will spend a good part of its time looping over the tags testing
    them one at a time to determine if it matches a given commit.
    For 10 tags this is not a big deal, but for hundreds of tags the
    time could become considerable if we don't find an exact match for
    the input commit and we need to walk back along the history chain.
    
    Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
    Signed-off-by: Junio C Hamano <junkio@cox.net>
  6. @spearce

    Always perfer annotated tags in git-describe.

    spearce authored Junio C Hamano committed
    Several people have suggested that its always better to describe
    a commit using an annotated tag, and to only use a lightweight tag
    if absolutely no annotated tag matches the input commit.
    
    Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
    Signed-off-by: Junio C Hamano <junkio@cox.net>
Commits on Jan 12, 2007
  1. @spearce

    Chose better tag names in git-describe after merges.

    spearce authored Junio C Hamano committed
    Recently git.git itself encountered a situation on its master and
    next branches where git-describe stopped reporting 'v1.5.0-rc0-gN'
    and instead started reporting 'v1.4.4.4-gN'.  This appeared to be
    a backward jump in version numbering.
    
      maint     o-------------------4
                \                    \
      master     o-o-o-o-o-o-o-5-o-C-o-W
    
    The issue is that commit C in the diagram claims it is version
    1.5.0, as the tag v1.5.0 is placed on commit 5.  Yet commit W
    claims it is version 1.4.4.4 as the tag v1.5.0 has an older tag
    date than the v1.4.4.4 tag.
    
    As it turns out this situation is very common.  A bug fix applied
    to maint and later merged into master occurs frequently enough that
    it should Just Work Right(tm).
    
    Rather than taking the first tag that gets found git-describe will
    now generate a list of all possible tags and select the one which
    has the most number of commits in common with HEAD (or whatever
    revision the user requested the description of).
    
    This rule is based on the principle shown in the diagram above.
    There are a large number of commits on the primary development branch
    'master' which do not appear in the 'maint' branch, and many of
    these are already tagged as part of v1.5.0-rc0.  Additionally these
    commits are not in v1.4.4.4, as they are part of the v1.5.0 release
    still being developed.  The v1.5.0-rc0 tag is more descriptive of
    W than v1.4.4.4 is, and therefore should be used.
    
    Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
    Signed-off-by: Junio C Hamano <junkio@cox.net>
Commits on Jan 10, 2007
  1. @spearce

    Make git-describe a builtin.

    spearce authored Junio C Hamano committed
    Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
    Signed-off-by: Junio C Hamano <junkio@cox.net>
Something went wrong with that request. Please try again.