summaryrefslogtreecommitdiff
path: root/builtin-describe.c
AgeCommit message (Collapse)AuthorFilesLines
2008-06-04describe: match pattern for lightweight tags tooLibravatar Michael Dressel1-4/+5
The <pattern> given "git describe --match" was used only to filter tag objects, and not to filter lightweight tags. This fixes it. [jc: made the log to clarify this is a bugfix, not an enhancement, with additional test] Signed-off-by: Michael Dressel <MichaelTiloDressel@t-online.de> Acked-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-03-08Merge branch 'jc/describe-always'Libravatar Junio C Hamano1-3/+14
* jc/describe-always: describe --always: fall back to showing an abbreviated object name
2008-03-03describe: re-fix display_name()Libravatar Junio C Hamano1-1/+1
It is implausible for lookup_tag() to return NULL in this particular codepath but we should protect ourselves against a broken repository better. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-03-03describe: fix --long outputLibravatar Junio C Hamano1-5/+11
An error while hand-merging broke the new "--long" option. This should fix it. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-03-03git-describe: use tags found in packed-refs correctlyLibravatar Junio C Hamano1-1/+1
When your refs are packed, "git-describe" can find the tag that is the best match without ever parsing the tag itself. But lookup_tag() in display_name() says "I've never seen it", creates an empty shell, and returns it. We need to make sure that we actually have parsed the tag data into it. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-03-03describe --always: fall back to showing an abbreviated object nameLibravatar Junio C Hamano1-3/+14
Some callers may find it useful if "git describe" always gave back a string that can be used as a shorter name for a commit object, rather than checking its exit status (while squelching its error message, which could potentially talk about more grave errors that should not be squelched) and implementing a fallback themselves. This teaches describe/name-rev a new option, --always, to use an abbreviated object name when no tags or refs to use is found. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-03-02Merge branch 'sp/describe-tag'Libravatar Junio C Hamano1-12/+33
* sp/describe-tag: Teach git-describe to verify annotated tag names before output Conflicts: builtin-describe.c
2008-03-02Merge branch 'sb/describe-long'Libravatar Junio C Hamano1-1/+10
* sb/describe-long: git-describe: --long shows the object name even for a tagged commit
2008-02-28Teach git-describe to verify annotated tag names before outputLibravatar Shawn O. Pearce1-8/+30
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>
2008-02-25git-describe: --long shows the object name even for a tagged commitLibravatar Santi Béjar1-1/+10
This is useful when you want to see parts of the commit object name in "describe" output, even when the commit in question happens to be a tagged version. Instead of just emitting the tag name, it will describe such a commit as v1.2-0-deadbeef (0th commit since tag v1.2 that points at object deadbeef....). Signed-off-by: Santi Béjar <sbejar@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-24Teach git-describe --exact-match to avoid expensive tag searchesLibravatar Shawn O. Pearce1-2/+6
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>
2008-02-24Avoid accessing non-tag refs in git-describe unless --all is requestedLibravatar Shawn O. Pearce1-1/+5
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>
2008-02-24Teach git-describe to use peeled ref information when scanning tagsLibravatar Shawn O. Pearce1-6/+17
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>
2007-12-26git-name-rev: add a --(no-)undefined option.Libravatar Pierre Habouzit1-1/+2
Rework get_rev_name to return NULL rather than "undefined" when a reference is undefined. If --undefined is passed (default), git-name-rev prints "undefined" for the name, else it die()s. Make git-describe use --no-undefined when calling git-name-rev so that --contains behavior matches the standard git-describe one. Signed-off-by: Pierre Habouzit <madcoder@debian.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-12-22git-describe: Add a --match option to limit considered tags.Libravatar Pierre Habouzit1-5/+16
Signed-off-by: Pierre Habouzit <madcoder@debian.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-12-19make 'git describe --all --contains' workLibravatar Nicolas Pitre1-6/+8
Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-10-29Make builtin-describe.c use parse_optionsLibravatar Pierre Habouzit1-41/+29
Signed-off-by: Pierre Habouzit <madcoder@debian.org> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-05-21Teach git-describe how to run name-revLibravatar Shawn O. Pearce1-0/+14
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>
2007-02-20Mechanical conversion to use prefixcmp()Libravatar Junio C Hamano1-3/+3
This mechanically converts strncmp() to use prefixcmp(), but only when the parameters match specific patterns, so that they can be verified easily. Leftover from this will be fixed in a separate step, including idiotic conversions like if (!strncmp("foo", arg, 3)) => if (!(-prefixcmp(arg, "foo"))) This was done by using this script in px.perl #!/usr/bin/perl -i.bak -p if (/strncmp\(([^,]+), "([^\\"]*)", (\d+)\)/ && (length($2) == $3)) { s|strncmp\(([^,]+), "([^\\"]*)", (\d+)\)|prefixcmp($1, "$2")|; } if (/strncmp\("([^\\"]*)", ([^,]+), (\d+)\)/ && (length($1) == $3)) { s|strncmp\("([^\\"]*)", ([^,]+), (\d+)\)|(-prefixcmp($2, "$1"))|; } and running: $ git grep -l strncmp -- '*.c' | xargs perl px.perl Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-28Compute accurate distances in git-describe before output.Libravatar Shawn O. Pearce1-1/+41
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>
2007-01-28Teach git-describe to display distances from tags.Libravatar Shawn O. Pearce1-2/+3
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>
2007-01-26If abbrev is set to zero in git-describe, don't add the unique suffixLibravatar Andy Parkins1-3/+6
When on a non-tag commit, git-describe normally outputs descriptions of the form v1.0.0-g1234567890 Some scripts (for example the update hook script) might just want to know the name of the nearest tag, so they then have to do x=$(git-describe HEAD | sed 's/-g*//') This is costly, but more importantly is fragile as it is relying on the output format of git-describe, which we would then have to maintain forever. This patch adds support for setting the --abbrev option to zero. In that case git-describe does as it always has, but outputs only the nearest found tag instead of a completely unique name. This means that scripts would not have to parse the output format and won't need changing if the git-describe suffix is ever changed. Signed-off-by: Andy Parkins <andyparkins@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-26Remove unnecessary found variable from describe.Libravatar Shawn O. Pearce1-2/+1
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>
2007-01-14Remove hash in git-describe in favor of util slot.Libravatar Shawn O. Pearce1-64/+12
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>
2007-01-14Correct priority of lightweight tags in git-describe.Libravatar Shawn O. Pearce1-12/+25
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>
2007-01-14Improve git-describe performance by reducing revision listing.Libravatar Shawn O. Pearce1-49/+76
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>
2007-01-14Use binary searching on large buckets in git-describe.Libravatar Shawn O. Pearce1-8/+21
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>
2007-01-14Hash tags by commit SHA1 in git-describe.Libravatar Shawn O. Pearce1-12/+17
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>
2007-01-14Always perfer annotated tags in git-describe.Libravatar Shawn O. Pearce1-11/+13
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>
2007-01-11plug a few leaks in revision walking used in describe.Libravatar Junio C Hamano1-0/+1
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-11Chose better tag names in git-describe after merges.Libravatar Shawn O. Pearce1-11/+67
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>
2007-01-10Make git-describe a builtin.Libravatar Shawn O. Pearce1-0/+176
Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>