git/builtin-describe.c

285 строки
6.6 KiB
C
Исходник Обычный вид История

Add a "git-describe" command It shows you the most recent tag that is reachable from a particular commit is. Maybe this is something that "git-name-rev" should be taught to do, instead of having a separate command for it. Regardless, I find it useful. What it does is to take any random commit, and "name" it by looking up the most recent commit that is tagged and reachable from that commit. If the match is exact, it will just print out that ref-name directly. Otherwise it will print out the ref-name, followed by the 8-character "short SHA". IOW, with something like Junios current tree, I get: [torvalds@g5 git]$ git-describe parent refs/tags/v1.0.4-g2414721b ie the current head of my "parent" branch (ie Junio) is based on v1.0.4, but since it has a few commits on top of that, it has added the git hash of the thing to the end: "-g" + 8-char shorthand for the commit 2414721b194453f058079d897d13c4e377f92dc6. Doing a "git-describe" on a tag-name will just show the full tag path: [torvalds@g5 git]$ git-describe v1.0.4 refs/tags/v1.0.4 unless there are _other_ tags pointing to that commit, in which case it will just choose one at random. This is useful for two things: - automatic version naming in Makefiles, for example. We could use it in git itself: when doing "git --version", we could use this to give a much more useful description of exactly what version was installed. - for any random commit (say, you use "gitk <pathname>" or "git-whatchanged" to look at what has changed in some file), you can figure out what the last version of the repo was. Ie, say I find a bug in commit 39ca371c45b04cd50d0974030ae051906fc516b6, I just do: [torvalds@g5 linux]$ git-describe 39ca371c45b04cd50d0974030ae051906fc516b6 refs/tags/v2.6.14-rc4-g39ca371c and I now know that it was _not_ in v2.6.14-rc4, but was presumably in v2.6.14-rc5. The latter is useful when you want to see what "version timeframe" a commit happened in. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-25 00:50:45 +03:00
#include "cache.h"
#include "commit.h"
#include "tag.h"
Add a "git-describe" command It shows you the most recent tag that is reachable from a particular commit is. Maybe this is something that "git-name-rev" should be taught to do, instead of having a separate command for it. Regardless, I find it useful. What it does is to take any random commit, and "name" it by looking up the most recent commit that is tagged and reachable from that commit. If the match is exact, it will just print out that ref-name directly. Otherwise it will print out the ref-name, followed by the 8-character "short SHA". IOW, with something like Junios current tree, I get: [torvalds@g5 git]$ git-describe parent refs/tags/v1.0.4-g2414721b ie the current head of my "parent" branch (ie Junio) is based on v1.0.4, but since it has a few commits on top of that, it has added the git hash of the thing to the end: "-g" + 8-char shorthand for the commit 2414721b194453f058079d897d13c4e377f92dc6. Doing a "git-describe" on a tag-name will just show the full tag path: [torvalds@g5 git]$ git-describe v1.0.4 refs/tags/v1.0.4 unless there are _other_ tags pointing to that commit, in which case it will just choose one at random. This is useful for two things: - automatic version naming in Makefiles, for example. We could use it in git itself: when doing "git --version", we could use this to give a much more useful description of exactly what version was installed. - for any random commit (say, you use "gitk <pathname>" or "git-whatchanged" to look at what has changed in some file), you can figure out what the last version of the repo was. Ie, say I find a bug in commit 39ca371c45b04cd50d0974030ae051906fc516b6, I just do: [torvalds@g5 linux]$ git-describe 39ca371c45b04cd50d0974030ae051906fc516b6 refs/tags/v2.6.14-rc4-g39ca371c and I now know that it was _not_ in v2.6.14-rc4, but was presumably in v2.6.14-rc5. The latter is useful when you want to see what "version timeframe" a commit happened in. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-25 00:50:45 +03:00
#include "refs.h"
#include "builtin.h"
Add a "git-describe" command It shows you the most recent tag that is reachable from a particular commit is. Maybe this is something that "git-name-rev" should be taught to do, instead of having a separate command for it. Regardless, I find it useful. What it does is to take any random commit, and "name" it by looking up the most recent commit that is tagged and reachable from that commit. If the match is exact, it will just print out that ref-name directly. Otherwise it will print out the ref-name, followed by the 8-character "short SHA". IOW, with something like Junios current tree, I get: [torvalds@g5 git]$ git-describe parent refs/tags/v1.0.4-g2414721b ie the current head of my "parent" branch (ie Junio) is based on v1.0.4, but since it has a few commits on top of that, it has added the git hash of the thing to the end: "-g" + 8-char shorthand for the commit 2414721b194453f058079d897d13c4e377f92dc6. Doing a "git-describe" on a tag-name will just show the full tag path: [torvalds@g5 git]$ git-describe v1.0.4 refs/tags/v1.0.4 unless there are _other_ tags pointing to that commit, in which case it will just choose one at random. This is useful for two things: - automatic version naming in Makefiles, for example. We could use it in git itself: when doing "git --version", we could use this to give a much more useful description of exactly what version was installed. - for any random commit (say, you use "gitk <pathname>" or "git-whatchanged" to look at what has changed in some file), you can figure out what the last version of the repo was. Ie, say I find a bug in commit 39ca371c45b04cd50d0974030ae051906fc516b6, I just do: [torvalds@g5 linux]$ git-describe 39ca371c45b04cd50d0974030ae051906fc516b6 refs/tags/v2.6.14-rc4-g39ca371c and I now know that it was _not_ in v2.6.14-rc4, but was presumably in v2.6.14-rc5. The latter is useful when you want to see what "version timeframe" a commit happened in. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-25 00:50:45 +03:00
Improve git-describe performance by reducing revision listing. 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-14 01:30:53 +03:00
#define SEEN (1u<<0)
#define MAX_TAGS (FLAG_BITS - 1)
static const char describe_usage[] =
"git-describe [--all] [--tags] [--abbrev=<n>] <committish>*";
Add a "git-describe" command It shows you the most recent tag that is reachable from a particular commit is. Maybe this is something that "git-name-rev" should be taught to do, instead of having a separate command for it. Regardless, I find it useful. What it does is to take any random commit, and "name" it by looking up the most recent commit that is tagged and reachable from that commit. If the match is exact, it will just print out that ref-name directly. Otherwise it will print out the ref-name, followed by the 8-character "short SHA". IOW, with something like Junios current tree, I get: [torvalds@g5 git]$ git-describe parent refs/tags/v1.0.4-g2414721b ie the current head of my "parent" branch (ie Junio) is based on v1.0.4, but since it has a few commits on top of that, it has added the git hash of the thing to the end: "-g" + 8-char shorthand for the commit 2414721b194453f058079d897d13c4e377f92dc6. Doing a "git-describe" on a tag-name will just show the full tag path: [torvalds@g5 git]$ git-describe v1.0.4 refs/tags/v1.0.4 unless there are _other_ tags pointing to that commit, in which case it will just choose one at random. This is useful for two things: - automatic version naming in Makefiles, for example. We could use it in git itself: when doing "git --version", we could use this to give a much more useful description of exactly what version was installed. - for any random commit (say, you use "gitk <pathname>" or "git-whatchanged" to look at what has changed in some file), you can figure out what the last version of the repo was. Ie, say I find a bug in commit 39ca371c45b04cd50d0974030ae051906fc516b6, I just do: [torvalds@g5 linux]$ git-describe 39ca371c45b04cd50d0974030ae051906fc516b6 refs/tags/v2.6.14-rc4-g39ca371c and I now know that it was _not_ in v2.6.14-rc4, but was presumably in v2.6.14-rc5. The latter is useful when you want to see what "version timeframe" a commit happened in. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-25 00:50:45 +03:00
Improve git-describe performance by reducing revision listing. 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-14 01:30:53 +03:00
static int debug; /* Display lots of verbose info */
static int all; /* Default to annotated tags only */
static int tags; /* But allow any tags if --tags is specified */
static int abbrev = DEFAULT_ABBREV;
Improve git-describe performance by reducing revision listing. 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-14 01:30:53 +03:00
static int max_candidates = 10;
Add a "git-describe" command It shows you the most recent tag that is reachable from a particular commit is. Maybe this is something that "git-name-rev" should be taught to do, instead of having a separate command for it. Regardless, I find it useful. What it does is to take any random commit, and "name" it by looking up the most recent commit that is tagged and reachable from that commit. If the match is exact, it will just print out that ref-name directly. Otherwise it will print out the ref-name, followed by the 8-character "short SHA". IOW, with something like Junios current tree, I get: [torvalds@g5 git]$ git-describe parent refs/tags/v1.0.4-g2414721b ie the current head of my "parent" branch (ie Junio) is based on v1.0.4, but since it has a few commits on top of that, it has added the git hash of the thing to the end: "-g" + 8-char shorthand for the commit 2414721b194453f058079d897d13c4e377f92dc6. Doing a "git-describe" on a tag-name will just show the full tag path: [torvalds@g5 git]$ git-describe v1.0.4 refs/tags/v1.0.4 unless there are _other_ tags pointing to that commit, in which case it will just choose one at random. This is useful for two things: - automatic version naming in Makefiles, for example. We could use it in git itself: when doing "git --version", we could use this to give a much more useful description of exactly what version was installed. - for any random commit (say, you use "gitk <pathname>" or "git-whatchanged" to look at what has changed in some file), you can figure out what the last version of the repo was. Ie, say I find a bug in commit 39ca371c45b04cd50d0974030ae051906fc516b6, I just do: [torvalds@g5 linux]$ git-describe 39ca371c45b04cd50d0974030ae051906fc516b6 refs/tags/v2.6.14-rc4-g39ca371c and I now know that it was _not_ in v2.6.14-rc4, but was presumably in v2.6.14-rc5. The latter is useful when you want to see what "version timeframe" a commit happened in. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-25 00:50:45 +03:00
struct commit_name {
int prio; /* annotated tag = 2, tag = 1, head = 0 */
2006-01-09 01:22:19 +03:00
char path[FLEX_ARRAY]; /* more */
};
static const char *prio_names[] = {
"head", "lightweight", "annotated",
};
Add a "git-describe" command It shows you the most recent tag that is reachable from a particular commit is. Maybe this is something that "git-name-rev" should be taught to do, instead of having a separate command for it. Regardless, I find it useful. What it does is to take any random commit, and "name" it by looking up the most recent commit that is tagged and reachable from that commit. If the match is exact, it will just print out that ref-name directly. Otherwise it will print out the ref-name, followed by the 8-character "short SHA". IOW, with something like Junios current tree, I get: [torvalds@g5 git]$ git-describe parent refs/tags/v1.0.4-g2414721b ie the current head of my "parent" branch (ie Junio) is based on v1.0.4, but since it has a few commits on top of that, it has added the git hash of the thing to the end: "-g" + 8-char shorthand for the commit 2414721b194453f058079d897d13c4e377f92dc6. Doing a "git-describe" on a tag-name will just show the full tag path: [torvalds@g5 git]$ git-describe v1.0.4 refs/tags/v1.0.4 unless there are _other_ tags pointing to that commit, in which case it will just choose one at random. This is useful for two things: - automatic version naming in Makefiles, for example. We could use it in git itself: when doing "git --version", we could use this to give a much more useful description of exactly what version was installed. - for any random commit (say, you use "gitk <pathname>" or "git-whatchanged" to look at what has changed in some file), you can figure out what the last version of the repo was. Ie, say I find a bug in commit 39ca371c45b04cd50d0974030ae051906fc516b6, I just do: [torvalds@g5 linux]$ git-describe 39ca371c45b04cd50d0974030ae051906fc516b6 refs/tags/v2.6.14-rc4-g39ca371c and I now know that it was _not_ in v2.6.14-rc4, but was presumably in v2.6.14-rc5. The latter is useful when you want to see what "version timeframe" a commit happened in. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-25 00:50:45 +03:00
static void add_to_known_names(const char *path,
Chose better tag names in git-describe after merges. 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-10 14:39:47 +03:00
struct commit *commit,
int prio)
Add a "git-describe" command It shows you the most recent tag that is reachable from a particular commit is. Maybe this is something that "git-name-rev" should be taught to do, instead of having a separate command for it. Regardless, I find it useful. What it does is to take any random commit, and "name" it by looking up the most recent commit that is tagged and reachable from that commit. If the match is exact, it will just print out that ref-name directly. Otherwise it will print out the ref-name, followed by the 8-character "short SHA". IOW, with something like Junios current tree, I get: [torvalds@g5 git]$ git-describe parent refs/tags/v1.0.4-g2414721b ie the current head of my "parent" branch (ie Junio) is based on v1.0.4, but since it has a few commits on top of that, it has added the git hash of the thing to the end: "-g" + 8-char shorthand for the commit 2414721b194453f058079d897d13c4e377f92dc6. Doing a "git-describe" on a tag-name will just show the full tag path: [torvalds@g5 git]$ git-describe v1.0.4 refs/tags/v1.0.4 unless there are _other_ tags pointing to that commit, in which case it will just choose one at random. This is useful for two things: - automatic version naming in Makefiles, for example. We could use it in git itself: when doing "git --version", we could use this to give a much more useful description of exactly what version was installed. - for any random commit (say, you use "gitk <pathname>" or "git-whatchanged" to look at what has changed in some file), you can figure out what the last version of the repo was. Ie, say I find a bug in commit 39ca371c45b04cd50d0974030ae051906fc516b6, I just do: [torvalds@g5 linux]$ git-describe 39ca371c45b04cd50d0974030ae051906fc516b6 refs/tags/v2.6.14-rc4-g39ca371c and I now know that it was _not_ in v2.6.14-rc4, but was presumably in v2.6.14-rc5. The latter is useful when you want to see what "version timeframe" a commit happened in. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-25 00:50:45 +03:00
{
struct commit_name *e = commit->util;
if (!e || e->prio < prio) {
size_t len = strlen(path)+1;
free(e);
e = xmalloc(sizeof(struct commit_name) + len);
e->prio = prio;
memcpy(e->path, path, len);
commit->util = e;
Add a "git-describe" command It shows you the most recent tag that is reachable from a particular commit is. Maybe this is something that "git-name-rev" should be taught to do, instead of having a separate command for it. Regardless, I find it useful. What it does is to take any random commit, and "name" it by looking up the most recent commit that is tagged and reachable from that commit. If the match is exact, it will just print out that ref-name directly. Otherwise it will print out the ref-name, followed by the 8-character "short SHA". IOW, with something like Junios current tree, I get: [torvalds@g5 git]$ git-describe parent refs/tags/v1.0.4-g2414721b ie the current head of my "parent" branch (ie Junio) is based on v1.0.4, but since it has a few commits on top of that, it has added the git hash of the thing to the end: "-g" + 8-char shorthand for the commit 2414721b194453f058079d897d13c4e377f92dc6. Doing a "git-describe" on a tag-name will just show the full tag path: [torvalds@g5 git]$ git-describe v1.0.4 refs/tags/v1.0.4 unless there are _other_ tags pointing to that commit, in which case it will just choose one at random. This is useful for two things: - automatic version naming in Makefiles, for example. We could use it in git itself: when doing "git --version", we could use this to give a much more useful description of exactly what version was installed. - for any random commit (say, you use "gitk <pathname>" or "git-whatchanged" to look at what has changed in some file), you can figure out what the last version of the repo was. Ie, say I find a bug in commit 39ca371c45b04cd50d0974030ae051906fc516b6, I just do: [torvalds@g5 linux]$ git-describe 39ca371c45b04cd50d0974030ae051906fc516b6 refs/tags/v2.6.14-rc4-g39ca371c and I now know that it was _not_ in v2.6.14-rc4, but was presumably in v2.6.14-rc5. The latter is useful when you want to see what "version timeframe" a commit happened in. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-25 00:50:45 +03:00
}
}
static int get_name(const char *path, const unsigned char *sha1, int flag, void *cb_data)
Add a "git-describe" command It shows you the most recent tag that is reachable from a particular commit is. Maybe this is something that "git-name-rev" should be taught to do, instead of having a separate command for it. Regardless, I find it useful. What it does is to take any random commit, and "name" it by looking up the most recent commit that is tagged and reachable from that commit. If the match is exact, it will just print out that ref-name directly. Otherwise it will print out the ref-name, followed by the 8-character "short SHA". IOW, with something like Junios current tree, I get: [torvalds@g5 git]$ git-describe parent refs/tags/v1.0.4-g2414721b ie the current head of my "parent" branch (ie Junio) is based on v1.0.4, but since it has a few commits on top of that, it has added the git hash of the thing to the end: "-g" + 8-char shorthand for the commit 2414721b194453f058079d897d13c4e377f92dc6. Doing a "git-describe" on a tag-name will just show the full tag path: [torvalds@g5 git]$ git-describe v1.0.4 refs/tags/v1.0.4 unless there are _other_ tags pointing to that commit, in which case it will just choose one at random. This is useful for two things: - automatic version naming in Makefiles, for example. We could use it in git itself: when doing "git --version", we could use this to give a much more useful description of exactly what version was installed. - for any random commit (say, you use "gitk <pathname>" or "git-whatchanged" to look at what has changed in some file), you can figure out what the last version of the repo was. Ie, say I find a bug in commit 39ca371c45b04cd50d0974030ae051906fc516b6, I just do: [torvalds@g5 linux]$ git-describe 39ca371c45b04cd50d0974030ae051906fc516b6 refs/tags/v2.6.14-rc4-g39ca371c and I now know that it was _not_ in v2.6.14-rc4, but was presumably in v2.6.14-rc5. The latter is useful when you want to see what "version timeframe" a commit happened in. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-25 00:50:45 +03:00
{
struct commit *commit = lookup_commit_reference_gently(sha1, 1);
struct object *object;
int prio;
Add a "git-describe" command It shows you the most recent tag that is reachable from a particular commit is. Maybe this is something that "git-name-rev" should be taught to do, instead of having a separate command for it. Regardless, I find it useful. What it does is to take any random commit, and "name" it by looking up the most recent commit that is tagged and reachable from that commit. If the match is exact, it will just print out that ref-name directly. Otherwise it will print out the ref-name, followed by the 8-character "short SHA". IOW, with something like Junios current tree, I get: [torvalds@g5 git]$ git-describe parent refs/tags/v1.0.4-g2414721b ie the current head of my "parent" branch (ie Junio) is based on v1.0.4, but since it has a few commits on top of that, it has added the git hash of the thing to the end: "-g" + 8-char shorthand for the commit 2414721b194453f058079d897d13c4e377f92dc6. Doing a "git-describe" on a tag-name will just show the full tag path: [torvalds@g5 git]$ git-describe v1.0.4 refs/tags/v1.0.4 unless there are _other_ tags pointing to that commit, in which case it will just choose one at random. This is useful for two things: - automatic version naming in Makefiles, for example. We could use it in git itself: when doing "git --version", we could use this to give a much more useful description of exactly what version was installed. - for any random commit (say, you use "gitk <pathname>" or "git-whatchanged" to look at what has changed in some file), you can figure out what the last version of the repo was. Ie, say I find a bug in commit 39ca371c45b04cd50d0974030ae051906fc516b6, I just do: [torvalds@g5 linux]$ git-describe 39ca371c45b04cd50d0974030ae051906fc516b6 refs/tags/v2.6.14-rc4-g39ca371c and I now know that it was _not_ in v2.6.14-rc4, but was presumably in v2.6.14-rc5. The latter is useful when you want to see what "version timeframe" a commit happened in. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-25 00:50:45 +03:00
if (!commit)
return 0;
object = parse_object(sha1);
/* If --all, then any refs are used.
* If --tags, then any tags are used.
* Otherwise only annotated tags are used.
*/
if (!strncmp(path, "refs/tags/", 10)) {
if (object->type == OBJ_TAG)
prio = 2;
else
prio = 1;
}
else
prio = 0;
if (!all) {
if (!prio)
return 0;
if (!tags && prio < 2)
return 0;
}
add_to_known_names(all ? path + 5 : path + 10, commit, prio);
Add a "git-describe" command It shows you the most recent tag that is reachable from a particular commit is. Maybe this is something that "git-name-rev" should be taught to do, instead of having a separate command for it. Regardless, I find it useful. What it does is to take any random commit, and "name" it by looking up the most recent commit that is tagged and reachable from that commit. If the match is exact, it will just print out that ref-name directly. Otherwise it will print out the ref-name, followed by the 8-character "short SHA". IOW, with something like Junios current tree, I get: [torvalds@g5 git]$ git-describe parent refs/tags/v1.0.4-g2414721b ie the current head of my "parent" branch (ie Junio) is based on v1.0.4, but since it has a few commits on top of that, it has added the git hash of the thing to the end: "-g" + 8-char shorthand for the commit 2414721b194453f058079d897d13c4e377f92dc6. Doing a "git-describe" on a tag-name will just show the full tag path: [torvalds@g5 git]$ git-describe v1.0.4 refs/tags/v1.0.4 unless there are _other_ tags pointing to that commit, in which case it will just choose one at random. This is useful for two things: - automatic version naming in Makefiles, for example. We could use it in git itself: when doing "git --version", we could use this to give a much more useful description of exactly what version was installed. - for any random commit (say, you use "gitk <pathname>" or "git-whatchanged" to look at what has changed in some file), you can figure out what the last version of the repo was. Ie, say I find a bug in commit 39ca371c45b04cd50d0974030ae051906fc516b6, I just do: [torvalds@g5 linux]$ git-describe 39ca371c45b04cd50d0974030ae051906fc516b6 refs/tags/v2.6.14-rc4-g39ca371c and I now know that it was _not_ in v2.6.14-rc4, but was presumably in v2.6.14-rc5. The latter is useful when you want to see what "version timeframe" a commit happened in. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-25 00:50:45 +03:00
return 0;
}
Chose better tag names in git-describe after merges. 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-10 14:39:47 +03:00
struct possible_tag {
struct commit_name *name;
int depth;
int found_order;
Improve git-describe performance by reducing revision listing. 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-14 01:30:53 +03:00
unsigned flag_within;
Chose better tag names in git-describe after merges. 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-10 14:39:47 +03:00
};
static int compare_pt(const void *a_, const void *b_)
{
struct possible_tag *a = (struct possible_tag *)a_;
struct possible_tag *b = (struct possible_tag *)b_;
if (a->name->prio != b->name->prio)
return b->name->prio - a->name->prio;
if (a->depth != b->depth)
return a->depth - b->depth;
if (a->found_order != b->found_order)
return a->found_order - b->found_order;
return 0;
}
Compute accurate distances in git-describe before output. 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-27 09:54:21 +03:00
static unsigned long finish_depth_computation(
struct commit_list **list,
struct possible_tag *best)
{
unsigned long seen_commits = 0;
while (*list) {
struct commit *c = pop_commit(list);
struct commit_list *parents = c->parents;
seen_commits++;
if (c->object.flags & best->flag_within) {
struct commit_list *a = *list;
while (a) {
struct commit *i = a->item;
if (!(i->object.flags & best->flag_within))
break;
a = a->next;
}
if (!a)
break;
} else
best->depth++;
while (parents) {
struct commit *p = parents->item;
parse_commit(p);
if (!(p->object.flags & SEEN))
insert_by_date(p, list);
p->object.flags |= c->object.flags;
parents = parents->next;
}
}
return seen_commits;
}
static void describe(const char *arg, int last_one)
Add a "git-describe" command It shows you the most recent tag that is reachable from a particular commit is. Maybe this is something that "git-name-rev" should be taught to do, instead of having a separate command for it. Regardless, I find it useful. What it does is to take any random commit, and "name" it by looking up the most recent commit that is tagged and reachable from that commit. If the match is exact, it will just print out that ref-name directly. Otherwise it will print out the ref-name, followed by the 8-character "short SHA". IOW, with something like Junios current tree, I get: [torvalds@g5 git]$ git-describe parent refs/tags/v1.0.4-g2414721b ie the current head of my "parent" branch (ie Junio) is based on v1.0.4, but since it has a few commits on top of that, it has added the git hash of the thing to the end: "-g" + 8-char shorthand for the commit 2414721b194453f058079d897d13c4e377f92dc6. Doing a "git-describe" on a tag-name will just show the full tag path: [torvalds@g5 git]$ git-describe v1.0.4 refs/tags/v1.0.4 unless there are _other_ tags pointing to that commit, in which case it will just choose one at random. This is useful for two things: - automatic version naming in Makefiles, for example. We could use it in git itself: when doing "git --version", we could use this to give a much more useful description of exactly what version was installed. - for any random commit (say, you use "gitk <pathname>" or "git-whatchanged" to look at what has changed in some file), you can figure out what the last version of the repo was. Ie, say I find a bug in commit 39ca371c45b04cd50d0974030ae051906fc516b6, I just do: [torvalds@g5 linux]$ git-describe 39ca371c45b04cd50d0974030ae051906fc516b6 refs/tags/v2.6.14-rc4-g39ca371c and I now know that it was _not_ in v2.6.14-rc4, but was presumably in v2.6.14-rc5. The latter is useful when you want to see what "version timeframe" a commit happened in. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-25 00:50:45 +03:00
{
unsigned char sha1[20];
Improve git-describe performance by reducing revision listing. 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-14 01:30:53 +03:00
struct commit *cmit, *gave_up_on = NULL;
Add a "git-describe" command It shows you the most recent tag that is reachable from a particular commit is. Maybe this is something that "git-name-rev" should be taught to do, instead of having a separate command for it. Regardless, I find it useful. What it does is to take any random commit, and "name" it by looking up the most recent commit that is tagged and reachable from that commit. If the match is exact, it will just print out that ref-name directly. Otherwise it will print out the ref-name, followed by the 8-character "short SHA". IOW, with something like Junios current tree, I get: [torvalds@g5 git]$ git-describe parent refs/tags/v1.0.4-g2414721b ie the current head of my "parent" branch (ie Junio) is based on v1.0.4, but since it has a few commits on top of that, it has added the git hash of the thing to the end: "-g" + 8-char shorthand for the commit 2414721b194453f058079d897d13c4e377f92dc6. Doing a "git-describe" on a tag-name will just show the full tag path: [torvalds@g5 git]$ git-describe v1.0.4 refs/tags/v1.0.4 unless there are _other_ tags pointing to that commit, in which case it will just choose one at random. This is useful for two things: - automatic version naming in Makefiles, for example. We could use it in git itself: when doing "git --version", we could use this to give a much more useful description of exactly what version was installed. - for any random commit (say, you use "gitk <pathname>" or "git-whatchanged" to look at what has changed in some file), you can figure out what the last version of the repo was. Ie, say I find a bug in commit 39ca371c45b04cd50d0974030ae051906fc516b6, I just do: [torvalds@g5 linux]$ git-describe 39ca371c45b04cd50d0974030ae051906fc516b6 refs/tags/v2.6.14-rc4-g39ca371c and I now know that it was _not_ in v2.6.14-rc4, but was presumably in v2.6.14-rc5. The latter is useful when you want to see what "version timeframe" a commit happened in. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-25 00:50:45 +03:00
struct commit_list *list;
static int initialized = 0;
struct commit_name *n;
struct possible_tag all_matches[MAX_TAGS];
Improve git-describe performance by reducing revision listing. 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-14 01:30:53 +03:00
unsigned int match_cnt = 0, annotated_cnt = 0, cur_match;
unsigned long seen_commits = 0;
Add a "git-describe" command It shows you the most recent tag that is reachable from a particular commit is. Maybe this is something that "git-name-rev" should be taught to do, instead of having a separate command for it. Regardless, I find it useful. What it does is to take any random commit, and "name" it by looking up the most recent commit that is tagged and reachable from that commit. If the match is exact, it will just print out that ref-name directly. Otherwise it will print out the ref-name, followed by the 8-character "short SHA". IOW, with something like Junios current tree, I get: [torvalds@g5 git]$ git-describe parent refs/tags/v1.0.4-g2414721b ie the current head of my "parent" branch (ie Junio) is based on v1.0.4, but since it has a few commits on top of that, it has added the git hash of the thing to the end: "-g" + 8-char shorthand for the commit 2414721b194453f058079d897d13c4e377f92dc6. Doing a "git-describe" on a tag-name will just show the full tag path: [torvalds@g5 git]$ git-describe v1.0.4 refs/tags/v1.0.4 unless there are _other_ tags pointing to that commit, in which case it will just choose one at random. This is useful for two things: - automatic version naming in Makefiles, for example. We could use it in git itself: when doing "git --version", we could use this to give a much more useful description of exactly what version was installed. - for any random commit (say, you use "gitk <pathname>" or "git-whatchanged" to look at what has changed in some file), you can figure out what the last version of the repo was. Ie, say I find a bug in commit 39ca371c45b04cd50d0974030ae051906fc516b6, I just do: [torvalds@g5 linux]$ git-describe 39ca371c45b04cd50d0974030ae051906fc516b6 refs/tags/v2.6.14-rc4-g39ca371c and I now know that it was _not_ in v2.6.14-rc4, but was presumably in v2.6.14-rc5. The latter is useful when you want to see what "version timeframe" a commit happened in. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-25 00:50:45 +03:00
if (get_sha1(arg, sha1))
die("Not a valid object name %s", arg);
cmit = lookup_commit_reference(sha1);
if (!cmit)
die("%s is not a valid '%s' object", arg, commit_type);
Add a "git-describe" command It shows you the most recent tag that is reachable from a particular commit is. Maybe this is something that "git-name-rev" should be taught to do, instead of having a separate command for it. Regardless, I find it useful. What it does is to take any random commit, and "name" it by looking up the most recent commit that is tagged and reachable from that commit. If the match is exact, it will just print out that ref-name directly. Otherwise it will print out the ref-name, followed by the 8-character "short SHA". IOW, with something like Junios current tree, I get: [torvalds@g5 git]$ git-describe parent refs/tags/v1.0.4-g2414721b ie the current head of my "parent" branch (ie Junio) is based on v1.0.4, but since it has a few commits on top of that, it has added the git hash of the thing to the end: "-g" + 8-char shorthand for the commit 2414721b194453f058079d897d13c4e377f92dc6. Doing a "git-describe" on a tag-name will just show the full tag path: [torvalds@g5 git]$ git-describe v1.0.4 refs/tags/v1.0.4 unless there are _other_ tags pointing to that commit, in which case it will just choose one at random. This is useful for two things: - automatic version naming in Makefiles, for example. We could use it in git itself: when doing "git --version", we could use this to give a much more useful description of exactly what version was installed. - for any random commit (say, you use "gitk <pathname>" or "git-whatchanged" to look at what has changed in some file), you can figure out what the last version of the repo was. Ie, say I find a bug in commit 39ca371c45b04cd50d0974030ae051906fc516b6, I just do: [torvalds@g5 linux]$ git-describe 39ca371c45b04cd50d0974030ae051906fc516b6 refs/tags/v2.6.14-rc4-g39ca371c and I now know that it was _not_ in v2.6.14-rc4, but was presumably in v2.6.14-rc5. The latter is useful when you want to see what "version timeframe" a commit happened in. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-25 00:50:45 +03:00
if (!initialized) {
initialized = 1;
for_each_ref(get_name, NULL);
Add a "git-describe" command It shows you the most recent tag that is reachable from a particular commit is. Maybe this is something that "git-name-rev" should be taught to do, instead of having a separate command for it. Regardless, I find it useful. What it does is to take any random commit, and "name" it by looking up the most recent commit that is tagged and reachable from that commit. If the match is exact, it will just print out that ref-name directly. Otherwise it will print out the ref-name, followed by the 8-character "short SHA". IOW, with something like Junios current tree, I get: [torvalds@g5 git]$ git-describe parent refs/tags/v1.0.4-g2414721b ie the current head of my "parent" branch (ie Junio) is based on v1.0.4, but since it has a few commits on top of that, it has added the git hash of the thing to the end: "-g" + 8-char shorthand for the commit 2414721b194453f058079d897d13c4e377f92dc6. Doing a "git-describe" on a tag-name will just show the full tag path: [torvalds@g5 git]$ git-describe v1.0.4 refs/tags/v1.0.4 unless there are _other_ tags pointing to that commit, in which case it will just choose one at random. This is useful for two things: - automatic version naming in Makefiles, for example. We could use it in git itself: when doing "git --version", we could use this to give a much more useful description of exactly what version was installed. - for any random commit (say, you use "gitk <pathname>" or "git-whatchanged" to look at what has changed in some file), you can figure out what the last version of the repo was. Ie, say I find a bug in commit 39ca371c45b04cd50d0974030ae051906fc516b6, I just do: [torvalds@g5 linux]$ git-describe 39ca371c45b04cd50d0974030ae051906fc516b6 refs/tags/v2.6.14-rc4-g39ca371c and I now know that it was _not_ in v2.6.14-rc4, but was presumably in v2.6.14-rc5. The latter is useful when you want to see what "version timeframe" a commit happened in. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-25 00:50:45 +03:00
}
n = cmit->util;
Add a "git-describe" command It shows you the most recent tag that is reachable from a particular commit is. Maybe this is something that "git-name-rev" should be taught to do, instead of having a separate command for it. Regardless, I find it useful. What it does is to take any random commit, and "name" it by looking up the most recent commit that is tagged and reachable from that commit. If the match is exact, it will just print out that ref-name directly. Otherwise it will print out the ref-name, followed by the 8-character "short SHA". IOW, with something like Junios current tree, I get: [torvalds@g5 git]$ git-describe parent refs/tags/v1.0.4-g2414721b ie the current head of my "parent" branch (ie Junio) is based on v1.0.4, but since it has a few commits on top of that, it has added the git hash of the thing to the end: "-g" + 8-char shorthand for the commit 2414721b194453f058079d897d13c4e377f92dc6. Doing a "git-describe" on a tag-name will just show the full tag path: [torvalds@g5 git]$ git-describe v1.0.4 refs/tags/v1.0.4 unless there are _other_ tags pointing to that commit, in which case it will just choose one at random. This is useful for two things: - automatic version naming in Makefiles, for example. We could use it in git itself: when doing "git --version", we could use this to give a much more useful description of exactly what version was installed. - for any random commit (say, you use "gitk <pathname>" or "git-whatchanged" to look at what has changed in some file), you can figure out what the last version of the repo was. Ie, say I find a bug in commit 39ca371c45b04cd50d0974030ae051906fc516b6, I just do: [torvalds@g5 linux]$ git-describe 39ca371c45b04cd50d0974030ae051906fc516b6 refs/tags/v2.6.14-rc4-g39ca371c and I now know that it was _not_ in v2.6.14-rc4, but was presumably in v2.6.14-rc5. The latter is useful when you want to see what "version timeframe" a commit happened in. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-25 00:50:45 +03:00
if (n) {
printf("%s\n", n->path);
return;
}
Improve git-describe performance by reducing revision listing. 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-14 01:30:53 +03:00
if (debug)
fprintf(stderr, "searching to describe %s\n", arg);
Add a "git-describe" command It shows you the most recent tag that is reachable from a particular commit is. Maybe this is something that "git-name-rev" should be taught to do, instead of having a separate command for it. Regardless, I find it useful. What it does is to take any random commit, and "name" it by looking up the most recent commit that is tagged and reachable from that commit. If the match is exact, it will just print out that ref-name directly. Otherwise it will print out the ref-name, followed by the 8-character "short SHA". IOW, with something like Junios current tree, I get: [torvalds@g5 git]$ git-describe parent refs/tags/v1.0.4-g2414721b ie the current head of my "parent" branch (ie Junio) is based on v1.0.4, but since it has a few commits on top of that, it has added the git hash of the thing to the end: "-g" + 8-char shorthand for the commit 2414721b194453f058079d897d13c4e377f92dc6. Doing a "git-describe" on a tag-name will just show the full tag path: [torvalds@g5 git]$ git-describe v1.0.4 refs/tags/v1.0.4 unless there are _other_ tags pointing to that commit, in which case it will just choose one at random. This is useful for two things: - automatic version naming in Makefiles, for example. We could use it in git itself: when doing "git --version", we could use this to give a much more useful description of exactly what version was installed. - for any random commit (say, you use "gitk <pathname>" or "git-whatchanged" to look at what has changed in some file), you can figure out what the last version of the repo was. Ie, say I find a bug in commit 39ca371c45b04cd50d0974030ae051906fc516b6, I just do: [torvalds@g5 linux]$ git-describe 39ca371c45b04cd50d0974030ae051906fc516b6 refs/tags/v2.6.14-rc4-g39ca371c and I now know that it was _not_ in v2.6.14-rc4, but was presumably in v2.6.14-rc5. The latter is useful when you want to see what "version timeframe" a commit happened in. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-25 00:50:45 +03:00
list = NULL;
Improve git-describe performance by reducing revision listing. 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-14 01:30:53 +03:00
cmit->object.flags = SEEN;
Add a "git-describe" command It shows you the most recent tag that is reachable from a particular commit is. Maybe this is something that "git-name-rev" should be taught to do, instead of having a separate command for it. Regardless, I find it useful. What it does is to take any random commit, and "name" it by looking up the most recent commit that is tagged and reachable from that commit. If the match is exact, it will just print out that ref-name directly. Otherwise it will print out the ref-name, followed by the 8-character "short SHA". IOW, with something like Junios current tree, I get: [torvalds@g5 git]$ git-describe parent refs/tags/v1.0.4-g2414721b ie the current head of my "parent" branch (ie Junio) is based on v1.0.4, but since it has a few commits on top of that, it has added the git hash of the thing to the end: "-g" + 8-char shorthand for the commit 2414721b194453f058079d897d13c4e377f92dc6. Doing a "git-describe" on a tag-name will just show the full tag path: [torvalds@g5 git]$ git-describe v1.0.4 refs/tags/v1.0.4 unless there are _other_ tags pointing to that commit, in which case it will just choose one at random. This is useful for two things: - automatic version naming in Makefiles, for example. We could use it in git itself: when doing "git --version", we could use this to give a much more useful description of exactly what version was installed. - for any random commit (say, you use "gitk <pathname>" or "git-whatchanged" to look at what has changed in some file), you can figure out what the last version of the repo was. Ie, say I find a bug in commit 39ca371c45b04cd50d0974030ae051906fc516b6, I just do: [torvalds@g5 linux]$ git-describe 39ca371c45b04cd50d0974030ae051906fc516b6 refs/tags/v2.6.14-rc4-g39ca371c and I now know that it was _not_ in v2.6.14-rc4, but was presumably in v2.6.14-rc5. The latter is useful when you want to see what "version timeframe" a commit happened in. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-25 00:50:45 +03:00
commit_list_insert(cmit, &list);
while (list) {
Chose better tag names in git-describe after merges. 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-10 14:39:47 +03:00
struct commit *c = pop_commit(&list);
struct commit_list *parents = c->parents;
Improve git-describe performance by reducing revision listing. 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-14 01:30:53 +03:00
seen_commits++;
n = c->util;
Add a "git-describe" command It shows you the most recent tag that is reachable from a particular commit is. Maybe this is something that "git-name-rev" should be taught to do, instead of having a separate command for it. Regardless, I find it useful. What it does is to take any random commit, and "name" it by looking up the most recent commit that is tagged and reachable from that commit. If the match is exact, it will just print out that ref-name directly. Otherwise it will print out the ref-name, followed by the 8-character "short SHA". IOW, with something like Junios current tree, I get: [torvalds@g5 git]$ git-describe parent refs/tags/v1.0.4-g2414721b ie the current head of my "parent" branch (ie Junio) is based on v1.0.4, but since it has a few commits on top of that, it has added the git hash of the thing to the end: "-g" + 8-char shorthand for the commit 2414721b194453f058079d897d13c4e377f92dc6. Doing a "git-describe" on a tag-name will just show the full tag path: [torvalds@g5 git]$ git-describe v1.0.4 refs/tags/v1.0.4 unless there are _other_ tags pointing to that commit, in which case it will just choose one at random. This is useful for two things: - automatic version naming in Makefiles, for example. We could use it in git itself: when doing "git --version", we could use this to give a much more useful description of exactly what version was installed. - for any random commit (say, you use "gitk <pathname>" or "git-whatchanged" to look at what has changed in some file), you can figure out what the last version of the repo was. Ie, say I find a bug in commit 39ca371c45b04cd50d0974030ae051906fc516b6, I just do: [torvalds@g5 linux]$ git-describe 39ca371c45b04cd50d0974030ae051906fc516b6 refs/tags/v2.6.14-rc4-g39ca371c and I now know that it was _not_ in v2.6.14-rc4, but was presumably in v2.6.14-rc5. The latter is useful when you want to see what "version timeframe" a commit happened in. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-25 00:50:45 +03:00
if (n) {
Improve git-describe performance by reducing revision listing. 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-14 01:30:53 +03:00
if (match_cnt < max_candidates) {
struct possible_tag *t = &all_matches[match_cnt++];
t->name = n;
t->depth = seen_commits - 1;
t->flag_within = 1u << match_cnt;
t->found_order = match_cnt;
Improve git-describe performance by reducing revision listing. 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-14 01:30:53 +03:00
c->object.flags |= t->flag_within;
if (n->prio == 2)
annotated_cnt++;
}
else {
gave_up_on = c;
break;
}
}
for (cur_match = 0; cur_match < match_cnt; cur_match++) {
struct possible_tag *t = &all_matches[cur_match];
if (!(c->object.flags & t->flag_within))
t->depth++;
}
if (annotated_cnt && !list) {
if (debug)
fprintf(stderr, "finished search at %s\n",
sha1_to_hex(c->object.sha1));
break;
}
while (parents) {
struct commit *p = parents->item;
parse_commit(p);
Improve git-describe performance by reducing revision listing. 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-14 01:30:53 +03:00
if (!(p->object.flags & SEEN))
insert_by_date(p, &list);
Improve git-describe performance by reducing revision listing. 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-14 01:30:53 +03:00
p->object.flags |= c->object.flags;
parents = parents->next;
Chose better tag names in git-describe after merges. 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-10 14:39:47 +03:00
}
}
Improve git-describe performance by reducing revision listing. 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-14 01:30:53 +03:00
if (!match_cnt)
Chose better tag names in git-describe after merges. 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-10 14:39:47 +03:00
die("cannot describe '%s'", sha1_to_hex(cmit->object.sha1));
qsort(all_matches, match_cnt, sizeof(all_matches[0]), compare_pt);
Compute accurate distances in git-describe before output. 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-27 09:54:21 +03:00
if (gave_up_on) {
insert_by_date(gave_up_on, &list);
seen_commits--;
}
seen_commits += finish_depth_computation(&list, &all_matches[0]);
free_commit_list(list);
Improve git-describe performance by reducing revision listing. 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-14 01:30:53 +03:00
if (debug) {
for (cur_match = 0; cur_match < match_cnt; cur_match++) {
struct possible_tag *t = &all_matches[cur_match];
fprintf(stderr, " %-11s %8d %s\n",
prio_names[t->name->prio],
Improve git-describe performance by reducing revision listing. 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-14 01:30:53 +03:00
t->depth, t->name->path);
}
fprintf(stderr, "traversed %lu commits\n", seen_commits);
if (gave_up_on) {
fprintf(stderr,
"more than %i tags found; listed %i most recent\n"
"gave up search at %s\n",
max_candidates, max_candidates,
sha1_to_hex(gave_up_on->object.sha1));
}
Chose better tag names in git-describe after merges. 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-10 14:39:47 +03:00
}
if (abbrev == 0)
printf("%s\n", all_matches[0].name->path );
else
printf("%s-%d-g%s\n", all_matches[0].name->path,
all_matches[0].depth,
find_unique_abbrev(cmit->object.sha1, abbrev));
Chose better tag names in git-describe after merges. 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-10 14:39:47 +03:00
Improve git-describe performance by reducing revision listing. 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-14 01:30:53 +03:00
if (!last_one)
clear_commit_marks(cmit, -1);
Add a "git-describe" command It shows you the most recent tag that is reachable from a particular commit is. Maybe this is something that "git-name-rev" should be taught to do, instead of having a separate command for it. Regardless, I find it useful. What it does is to take any random commit, and "name" it by looking up the most recent commit that is tagged and reachable from that commit. If the match is exact, it will just print out that ref-name directly. Otherwise it will print out the ref-name, followed by the 8-character "short SHA". IOW, with something like Junios current tree, I get: [torvalds@g5 git]$ git-describe parent refs/tags/v1.0.4-g2414721b ie the current head of my "parent" branch (ie Junio) is based on v1.0.4, but since it has a few commits on top of that, it has added the git hash of the thing to the end: "-g" + 8-char shorthand for the commit 2414721b194453f058079d897d13c4e377f92dc6. Doing a "git-describe" on a tag-name will just show the full tag path: [torvalds@g5 git]$ git-describe v1.0.4 refs/tags/v1.0.4 unless there are _other_ tags pointing to that commit, in which case it will just choose one at random. This is useful for two things: - automatic version naming in Makefiles, for example. We could use it in git itself: when doing "git --version", we could use this to give a much more useful description of exactly what version was installed. - for any random commit (say, you use "gitk <pathname>" or "git-whatchanged" to look at what has changed in some file), you can figure out what the last version of the repo was. Ie, say I find a bug in commit 39ca371c45b04cd50d0974030ae051906fc516b6, I just do: [torvalds@g5 linux]$ git-describe 39ca371c45b04cd50d0974030ae051906fc516b6 refs/tags/v2.6.14-rc4-g39ca371c and I now know that it was _not_ in v2.6.14-rc4, but was presumably in v2.6.14-rc5. The latter is useful when you want to see what "version timeframe" a commit happened in. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-25 00:50:45 +03:00
}
int cmd_describe(int argc, const char **argv, const char *prefix)
Add a "git-describe" command It shows you the most recent tag that is reachable from a particular commit is. Maybe this is something that "git-name-rev" should be taught to do, instead of having a separate command for it. Regardless, I find it useful. What it does is to take any random commit, and "name" it by looking up the most recent commit that is tagged and reachable from that commit. If the match is exact, it will just print out that ref-name directly. Otherwise it will print out the ref-name, followed by the 8-character "short SHA". IOW, with something like Junios current tree, I get: [torvalds@g5 git]$ git-describe parent refs/tags/v1.0.4-g2414721b ie the current head of my "parent" branch (ie Junio) is based on v1.0.4, but since it has a few commits on top of that, it has added the git hash of the thing to the end: "-g" + 8-char shorthand for the commit 2414721b194453f058079d897d13c4e377f92dc6. Doing a "git-describe" on a tag-name will just show the full tag path: [torvalds@g5 git]$ git-describe v1.0.4 refs/tags/v1.0.4 unless there are _other_ tags pointing to that commit, in which case it will just choose one at random. This is useful for two things: - automatic version naming in Makefiles, for example. We could use it in git itself: when doing "git --version", we could use this to give a much more useful description of exactly what version was installed. - for any random commit (say, you use "gitk <pathname>" or "git-whatchanged" to look at what has changed in some file), you can figure out what the last version of the repo was. Ie, say I find a bug in commit 39ca371c45b04cd50d0974030ae051906fc516b6, I just do: [torvalds@g5 linux]$ git-describe 39ca371c45b04cd50d0974030ae051906fc516b6 refs/tags/v2.6.14-rc4-g39ca371c and I now know that it was _not_ in v2.6.14-rc4, but was presumably in v2.6.14-rc5. The latter is useful when you want to see what "version timeframe" a commit happened in. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-25 00:50:45 +03:00
{
int i;
for (i = 1; i < argc; i++) {
const char *arg = argv[i];
if (*arg != '-')
break;
Improve git-describe performance by reducing revision listing. 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-14 01:30:53 +03:00
else if (!strcmp(arg, "--debug"))
debug = 1;
else if (!strcmp(arg, "--all"))
Add a "git-describe" command It shows you the most recent tag that is reachable from a particular commit is. Maybe this is something that "git-name-rev" should be taught to do, instead of having a separate command for it. Regardless, I find it useful. What it does is to take any random commit, and "name" it by looking up the most recent commit that is tagged and reachable from that commit. If the match is exact, it will just print out that ref-name directly. Otherwise it will print out the ref-name, followed by the 8-character "short SHA". IOW, with something like Junios current tree, I get: [torvalds@g5 git]$ git-describe parent refs/tags/v1.0.4-g2414721b ie the current head of my "parent" branch (ie Junio) is based on v1.0.4, but since it has a few commits on top of that, it has added the git hash of the thing to the end: "-g" + 8-char shorthand for the commit 2414721b194453f058079d897d13c4e377f92dc6. Doing a "git-describe" on a tag-name will just show the full tag path: [torvalds@g5 git]$ git-describe v1.0.4 refs/tags/v1.0.4 unless there are _other_ tags pointing to that commit, in which case it will just choose one at random. This is useful for two things: - automatic version naming in Makefiles, for example. We could use it in git itself: when doing "git --version", we could use this to give a much more useful description of exactly what version was installed. - for any random commit (say, you use "gitk <pathname>" or "git-whatchanged" to look at what has changed in some file), you can figure out what the last version of the repo was. Ie, say I find a bug in commit 39ca371c45b04cd50d0974030ae051906fc516b6, I just do: [torvalds@g5 linux]$ git-describe 39ca371c45b04cd50d0974030ae051906fc516b6 refs/tags/v2.6.14-rc4-g39ca371c and I now know that it was _not_ in v2.6.14-rc4, but was presumably in v2.6.14-rc5. The latter is useful when you want to see what "version timeframe" a commit happened in. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-25 00:50:45 +03:00
all = 1;
else if (!strcmp(arg, "--tags"))
tags = 1;
else if (!strncmp(arg, "--abbrev=", 9)) {
abbrev = strtoul(arg + 9, NULL, 10);
if (abbrev != 0 && (abbrev < MINIMUM_ABBREV || 40 < abbrev))
abbrev = DEFAULT_ABBREV;
}
Improve git-describe performance by reducing revision listing. 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-14 01:30:53 +03:00
else if (!strncmp(arg, "--candidates=", 13)) {
max_candidates = strtoul(arg + 13, NULL, 10);
if (max_candidates < 1)
max_candidates = 1;
else if (max_candidates > MAX_TAGS)
max_candidates = MAX_TAGS;
}
else
Add a "git-describe" command It shows you the most recent tag that is reachable from a particular commit is. Maybe this is something that "git-name-rev" should be taught to do, instead of having a separate command for it. Regardless, I find it useful. What it does is to take any random commit, and "name" it by looking up the most recent commit that is tagged and reachable from that commit. If the match is exact, it will just print out that ref-name directly. Otherwise it will print out the ref-name, followed by the 8-character "short SHA". IOW, with something like Junios current tree, I get: [torvalds@g5 git]$ git-describe parent refs/tags/v1.0.4-g2414721b ie the current head of my "parent" branch (ie Junio) is based on v1.0.4, but since it has a few commits on top of that, it has added the git hash of the thing to the end: "-g" + 8-char shorthand for the commit 2414721b194453f058079d897d13c4e377f92dc6. Doing a "git-describe" on a tag-name will just show the full tag path: [torvalds@g5 git]$ git-describe v1.0.4 refs/tags/v1.0.4 unless there are _other_ tags pointing to that commit, in which case it will just choose one at random. This is useful for two things: - automatic version naming in Makefiles, for example. We could use it in git itself: when doing "git --version", we could use this to give a much more useful description of exactly what version was installed. - for any random commit (say, you use "gitk <pathname>" or "git-whatchanged" to look at what has changed in some file), you can figure out what the last version of the repo was. Ie, say I find a bug in commit 39ca371c45b04cd50d0974030ae051906fc516b6, I just do: [torvalds@g5 linux]$ git-describe 39ca371c45b04cd50d0974030ae051906fc516b6 refs/tags/v2.6.14-rc4-g39ca371c and I now know that it was _not_ in v2.6.14-rc4, but was presumably in v2.6.14-rc5. The latter is useful when you want to see what "version timeframe" a commit happened in. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-25 00:50:45 +03:00
usage(describe_usage);
}
save_commit_buffer = 0;
if (argc <= i)
2006-01-16 09:25:35 +03:00
describe("HEAD", 1);
else
2006-01-16 09:25:35 +03:00
while (i < argc) {
describe(argv[i], (i == argc - 1));
i++;
}
Add a "git-describe" command It shows you the most recent tag that is reachable from a particular commit is. Maybe this is something that "git-name-rev" should be taught to do, instead of having a separate command for it. Regardless, I find it useful. What it does is to take any random commit, and "name" it by looking up the most recent commit that is tagged and reachable from that commit. If the match is exact, it will just print out that ref-name directly. Otherwise it will print out the ref-name, followed by the 8-character "short SHA". IOW, with something like Junios current tree, I get: [torvalds@g5 git]$ git-describe parent refs/tags/v1.0.4-g2414721b ie the current head of my "parent" branch (ie Junio) is based on v1.0.4, but since it has a few commits on top of that, it has added the git hash of the thing to the end: "-g" + 8-char shorthand for the commit 2414721b194453f058079d897d13c4e377f92dc6. Doing a "git-describe" on a tag-name will just show the full tag path: [torvalds@g5 git]$ git-describe v1.0.4 refs/tags/v1.0.4 unless there are _other_ tags pointing to that commit, in which case it will just choose one at random. This is useful for two things: - automatic version naming in Makefiles, for example. We could use it in git itself: when doing "git --version", we could use this to give a much more useful description of exactly what version was installed. - for any random commit (say, you use "gitk <pathname>" or "git-whatchanged" to look at what has changed in some file), you can figure out what the last version of the repo was. Ie, say I find a bug in commit 39ca371c45b04cd50d0974030ae051906fc516b6, I just do: [torvalds@g5 linux]$ git-describe 39ca371c45b04cd50d0974030ae051906fc516b6 refs/tags/v2.6.14-rc4-g39ca371c and I now know that it was _not_ in v2.6.14-rc4, but was presumably in v2.6.14-rc5. The latter is useful when you want to see what "version timeframe" a commit happened in. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-25 00:50:45 +03:00
return 0;
}