{"thread":{"id":"21263","subject":"[PATCH RFC] git describe without refs distinguishes dirty working tree","startedAt":"2009-10-16T15:12:08Z","lastAt":"2009-10-17T00:31:20Z","messageCount":8,"participants":["Jean Privat","Junio C Hamano","Shawn O. Pearce","Nicolas Pitre"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"125184","messageId":"dffdbd190910160812h6d6a876el8261a622b5439b30@mail.gmail.com","threadId":"21263","inReplyTo":null,"subject":"[PATCH RFC] git describe without refs distinguishes dirty working tree","fromName":"Jean Privat","fromEmail":"jean@pryen.org","sentAt":"2009-10-16T15:12:08Z","receivedAt":"2009-10-16T15:12:08Z","isPatch":true,"sender":{"key":"jean@pryen.org","avatar":"https://avatars.githubusercontent.com/u/135828?v=4"},"body":"git describe without refs still works on HEAD but append \"-dirty\" if the\nworking three is dirty. If the working tree is clean, nothing is appended.\n\nPrevious behavior can be achieved by specifying \"HEAD\".\n\nMany build scripts use `git describe` to produce a version number.\nHowever, additional git commands are required to distinguish builds done\nwith a clean tree from builds done with a dirty tree.\nThis patch helps the writing of these scripts since `git describe` do\nthe intended thing.\n\nThis new behavior could affect existing scripts by producing version\nnumber like v1.0.4-14-g2414721-dirty-dirty.\nThese scripts could be easily fixed by explicitly using HEAD when calling\n`git describe` and works with any version of git.\n\nSigned-off-by: Jean Privat <jean@pryen.org>\n---\n\nInitially, I wanted to add an option `--worktree` that works on HEAD and\nappends \"-dirty\" when the working tree is dirty. After rethink I\nrealized that users (me included) should prefer to describe the working\ntree by default, and only describe HEAD if HEAD was explicitly specified.\n\nNote that documentation of `git describe` did not mentioned the behavior\nof the command when no committish is specified.\nHowever, since it is still a behavior change. If the patch is accepted,\nit could target version 1.7.\n---\n Documentation/git-describe.txt |    5 ++++-\n builtin-describe.c             |   18 +++++++++++++++++-\n t/t6120-describe.sh            |    8 ++++++++\n 3 files changed, 29 insertions(+), 2 deletions(-)\n\ndiff --git a/Documentation/git-describe.txt b/Documentation/git-describe.txt\nindex b231dbb..c49ecc8 100644\n--- a/Documentation/git-describe.txt\n+++ b/Documentation/git-describe.txt\n@@ -8,7 +8,7 @@ git-describe - Show the most recent tag that is\nreachable from a commit\n\n SYNOPSIS\n --------\n-'git describe' [--all] [--tags] [--contains] [--abbrev=<n>] <committish>...\n+'git describe' [--all] [--tags] [--contains] [--abbrev=<n>] [<committish>...]\n\n DESCRIPTION\n -----------\n@@ -18,6 +18,9 @@ shown.  Otherwise, it suffixes the tag name with the number of\n additional commits on top of the tagged object and the\n abbreviated object name of the most recent commit.\n\n+Without any committish, `git describe` opperates on HEAD and\n+appends \"-dirty\" if the working tree is dirty.\n+\n By default (without --all or --tags) `git describe` only shows\n annotated tags.  For more information about creating annotated tags\n see the -a and -s options to linkgit:git-tag[1].\ndiff --git a/builtin-describe.c b/builtin-describe.c\nindex df67a73..4105d9c 100644\n--- a/builtin-describe.c\n+++ b/builtin-describe.c\n@@ -5,6 +5,7 @@\n #include \"builtin.h\"\n #include \"exec_cmd.h\"\n #include \"parse-options.h\"\n+#include \"diff.h\"\n\n #define SEEN\t\t(1u<<0)\n #define MAX_TAGS\t(FLAG_BITS - 1)\n@@ -23,6 +24,13 @@ static int max_candidates = 10;\n static int found_names;\n static const char *pattern;\n static int always;\n+static int dirty; /* Is working tree dirty? */\n+\n+/* diff-index command arguments to check if working tree is dirty. */\n+static const char *diff_index_args[] = {\n+\t\"diff-index\", \"--quiet\", \"HEAD\", \"--\", NULL\n+};\n+\n\n struct commit_name {\n \tstruct tag *tag;\n@@ -208,6 +216,8 @@ static void describe(const char *arg, int last_one)\n \t\tdisplay_name(n);\n \t\tif (longformat)\n \t\t\tshow_suffix(0, n->tag ? n->tag->tagged->sha1 : sha1);\n+\t\tif (dirty)\n+\t\t\tprintf(\"-dirty\");\n \t\tprintf(\"\\n\");\n \t\treturn;\n \t}\n@@ -265,7 +275,10 @@ static void describe(const char *arg, int last_one)\n \tif (!match_cnt) {\n \t\tconst unsigned char *sha1 = cmit->object.sha1;\n \t\tif (always) {\n-\t\t\tprintf(\"%s\\n\", find_unique_abbrev(sha1, abbrev));\n+\t\t\tprintf(\"%s\", find_unique_abbrev(sha1, abbrev));\n+\t\t\tif (dirty)\n+\t\t\t\tprintf(\"-dirty\");\n+\t\t\tprintf(\"\\n\");\n \t\t\treturn;\n \t\t}\n \t\tdie(\"cannot describe '%s'\", sha1_to_hex(sha1));\n@@ -300,6 +313,8 @@ static void describe(const char *arg, int last_one)\n \tdisplay_name(all_matches[0].name);\n \tif (abbrev)\n \t\tshow_suffix(all_matches[0].depth, cmit->object.sha1);\n+\tif (dirty)\n+\t\tprintf(\"-dirty\");\n \tprintf(\"\\n\");\n\n \tif (!last_one)\n@@ -360,6 +375,7 @@ int cmd_describe(int argc, const char **argv,\nconst char *prefix)\n \t}\n\n \tif (argc == 0) {\n+\t\tdirty = cmd_diff_index(ARRAY_SIZE(diff_index_args) - 1,\ndiff_index_args, prefix);\n \t\tdescribe(\"HEAD\", 1);\n \t} else {\n \t\twhile (argc-- > 0) {\ndiff --git a/t/t6120-describe.sh b/t/t6120-describe.sh\nindex 8c7e081..8938fc6 100755\n--- a/t/t6120-describe.sh\n+++ b/t/t6120-describe.sh\n@@ -123,6 +123,14 @@ test_expect_success 'rename tag Q back to A' '\n test_expect_success 'pack tag refs' 'git pack-refs'\n check_describe A-* HEAD\n\n+test_expect_success 'set-up dirty working tree' '\n+\techo >>file\n+'\n+\n+check_describe \"A-*[0-9a-f]-dirty\"\n+\n+check_describe \"A-*[0-9a-f]\" HEAD\n+\n test_expect_success 'set-up matching pattern tests' '\n \tgit tag -a -m test-annotated test-annotated &&\n \techo >>file &&\n-- \n1.6.5\n"},{"id":"125195","messageId":"7vd44nuu6g.fsf@alter.siamese.dyndns.org","threadId":"21263","inReplyTo":"dffdbd190910160812h6d6a876el8261a622b5439b30@mail.gmail.com","subject":"Re: [PATCH RFC] git describe without refs distinguishes dirty working tree","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-10-16T17:26:15Z","receivedAt":"2009-10-16T17:26:15Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jean Privat <jean@pryen.org> writes:\n\n> ...\n> This new behavior could affect existing scripts by producing version\n> number like v1.0.4-14-g2414721-dirty-dirty.\n> These scripts could be easily fixed by explicitly using HEAD when calling\n> `git describe` and works with any version of git.\n>\n> Signed-off-by: Jean Privat <jean@pryen.org>\n> ---\n>\n> Initially, I wanted to add an option `--worktree` that works on HEAD and\n> appends \"-dirty\" when the working tree is dirty. After rethink I\n> realized that users (me included) should prefer to describe the working\n> tree by default, and only describe HEAD if HEAD was explicitly specified.\n>\n> Note that documentation of `git describe` did not mentioned the behavior\n> of the command when no committish is specified.\n> However, since it is still a behavior change. If the patch is accepted,\n> it could target version 1.7.\n> ---\n>  Documentation/git-describe.txt |    5 ++++-\n>  builtin-describe.c             |   18 +++++++++++++++++-\n>  t/t6120-describe.sh            |    8 ++++++++\n>  3 files changed, 29 insertions(+), 2 deletions(-)\n>\n> diff --git a/Documentation/git-describe.txt b/Documentation/git-describe.txt\n> index b231dbb..c49ecc8 100644\n> --- a/Documentation/git-describe.txt\n> +++ b/Documentation/git-describe.txt\n> @@ -8,7 +8,7 @@ git-describe - Show the most recent tag that is\n> reachable from a commit\n\nHere is an indication of a linewrapped and broken patch that discourages\nme to look further.\n\nAs to the new _ability_, I think it would make sense to reduce the need\nfor an extra invocation of \"is the work tree dirty\" and this addition is a\nwelcomed one in that sense.  However, as you already are aware of, this\nwill break existing scripts; it should not trigger for them.\n\nHow about \"describe --dirty\" and \"describe --dirty=-mod\" (the latter\ncreates v1.6.5-15-gc274db7-mod\"), possibly with a short version of options\nif this proves to be useful and frequently used from interactive sessions?\n\nI personally think this does not deserve to have a short option (as you\nsaid in the log message, it is primarily a way to make up a version number\nstring, and give interactive users a sense of where in the history he is.\nIf you want to know if your tree is dirty, depending on the reason _why_\nyou want to know it and what you want to do with the information after\nlearning your tree is dirty, \"status\", \"diff --stat\", \"add -i\" are more\nappropriate and useful tools) but you (and others) may bring up use cases\nthat I didn't think of when I wrote the beginning of this sentence ;-)\n"},{"id":"125197","messageId":"20091016173902.GT10505@spearce.org","threadId":"21263","inReplyTo":"dffdbd190910160812h6d6a876el8261a622b5439b30@mail.gmail.com","subject":"Re: [PATCH RFC] git describe without refs distinguishes dirty working tree","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2009-10-16T17:39:02Z","receivedAt":"2009-10-16T17:39:02Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Jean Privat <jean@pryen.org> wrote:\n> git describe without refs still works on HEAD but append \"-dirty\" if the\n> working three is dirty. If the working tree is clean, nothing is appended.\n> \n> Previous behavior can be achieved by specifying \"HEAD\".\n> \n> Many build scripts use `git describe` to produce a version number.\n> However, additional git commands are required to distinguish builds done\n> with a clean tree from builds done with a dirty tree.\n> This patch helps the writing of these scripts since `git describe` do\n> the intended thing.\n> \n> This new behavior could affect existing scripts by producing version\n> number like v1.0.4-14-g2414721-dirty-dirty.\n> These scripts could be easily fixed by explicitly using HEAD when calling\n> `git describe` and works with any version of git.\n> \n> Signed-off-by: Jean Privat <jean@pryen.org>\n\nYea, I think this is reasonable and sane thing to do.\n\nAcked-by: Shawn O. Pearce <spearce@spearce.org>\n\n> Note that documentation of `git describe` did not mentioned the behavior\n> of the command when no committish is specified.\n> However, since it is still a behavior change. If the patch is accepted,\n> it could target version 1.7.\n\nYea, 1.7 may be safer for this, but also many scripts are based\non the GIT-VERSION-GEN in git.git which uses HEAD as an explicit\nargument.  So they might actually be OK with this change.\n\n-- \nShawn.\n"},{"id":"125208","messageId":"7veip3t6rm.fsf@alter.siamese.dyndns.org","threadId":"21263","inReplyTo":"20091016173902.GT10505@spearce.org","subject":"Re: [PATCH RFC] git describe without refs distinguishes dirty working tree","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-10-16T20:37:17Z","receivedAt":"2009-10-16T20:37:17Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Shawn O. Pearce\" <spearce@spearce.org> writes:\n\n> Yea, 1.7 may be safer for this, but also many scripts are based\n> on the GIT-VERSION-GEN in git.git which uses HEAD as an explicit\n> argument.  So they might actually be OK with this change.\n\nWell, from my cursory look of its scripts/setlocalversion, even the Linux\nkernel is not safe X-<.\n\nI still haven't heard anything that helps me to decide which way the\ndefault should be.  The only concrete thing I have heard against the\nchange of the default is that it will break existing setup, but I haven't\nheard anything concrete for the change yet.\n"},{"id":"125211","messageId":"dffdbd190910161452o4ac0b426i7c48649eafa0d53@mail.gmail.com","threadId":"21263","inReplyTo":"7veip3t6rm.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH RFC] git describe without refs distinguishes dirty working tree","fromName":"Jean Privat","fromEmail":"jean@pryen.org","sentAt":"2009-10-16T21:52:21Z","receivedAt":"2009-10-16T21:52:21Z","isPatch":true,"sender":{"key":"jean@pryen.org","avatar":"https://avatars.githubusercontent.com/u/135828?v=4"},"body":"> I still haven't heard anything that helps me to decide which way the\n> default should be.  The only concrete thing I have heard against the\n> change of the default is that it will break existing setup, but I haven't\n> heard anything concrete for the change yet.\n\nAs a said in the comment part of the initial message, I initially\nplaned to add a --worktree option that means \"I want you to describe\nmy working tree\". Knowing that from my naive point of view, the\ndescription of the working tree is what build script wanted :\ndescription of HEAD (on which is based the working tree) + saying that\nif the working tree is dirty or not (done manually by scripts).\nMoreover, in my naive view with the \"--worktree\" option, no refs where\nallowed (i.e. describe the working tree xor describe some commit\nreferences).\n\nThen, I realized that for some other git commands that can work both\non the working tree and on an arbitrary commit reference, the default\nwas to work on the working tree and require an explicit HEAD to work\non the HEAD commit. Thus it makes sense to me that \"git describe\"\nalone should describe the working tree and that \"git describe HEAD\"\nshould describe the HEAD commit.\nMoreover, since build scripts use \"git describe\" not to describe an\narbitrary commit but to describe the working tree, it is nice to make\nwhat thez really want the default.\n\nCurrently, the breaking of scripts is the only reason that makes me\nnot entirely convinced that default should be to describe the working\ntree. But I think that if \"git describe\" could be redesigned,\ndescribing the working tree by default should be the right thing.\nI also think that the breakage should not be so important:\n* it could be fixed without requiring/checking a specific git version\n* it appears only for people that build on a dirty tree\n* the effect may be only to produce a strange version number\n* git describe is porcelain :)\n* 1.7 may break other things, so some fixing me be required anyway :).\n\nIf git people prefers that default remains HEAD, I have no real strong\nobjection (I still have to resend the patch because of line breaking\nanyway).\n\n> How about \"describe --dirty\" and \"describe --dirty=-mod\" (the latter\n> creates v1.6.5-15-gc274db7-mod\")\n\nMay be better than \"--wortree\" (especially because of the value part),\nbut what happen with\n $ git describe --dirty v1.2.1\nshould it show an error, output \"v1.2.1\" anyway, or output\n\"v1.2.1-dirty\" if the working tree is different from v1.2.1 ?\n\n-J\n"},{"id":"125214","messageId":"20091016223742.GV10505@spearce.org","threadId":"21263","inReplyTo":"dffdbd190910161452o4ac0b426i7c48649eafa0d53@mail.gmail.com","subject":"Re: [PATCH RFC] git describe without refs distinguishes dirty working tree","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2009-10-16T22:37:42Z","receivedAt":"2009-10-16T22:37:42Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Jean Privat <jean@pryen.org> wrote:\n> > I still haven't heard anything that helps me to decide which way the\n> > default should be.  The only concrete thing I have heard against the\n> > change of the default is that it will break existing setup, but I haven't\n> > heard anything concrete for the change yet.\n...\n> Then, I realized that for some other git commands that can work both\n> on the working tree and on an arbitrary commit reference, the default\n> was to work on the working tree and require an explicit HEAD to work\n> on the HEAD commit. Thus it makes sense to me that \"git describe\"\n> alone should describe the working tree and that \"git describe HEAD\"\n> should describe the HEAD commit.\n\nYup.  That's my take on it too.  This default of \"no argument means\ndescribe the working tree\" matches with tools like `git diff`,\n`git checkout`, `git status`, `git blame` with no revision arguments.\n\nWe are being blasted by users for being inconsistent in our UI in too\nmany places.  Here's yet another.  We need to start standardizing\non a more consistent UI model.  If that model means we need to\nuse a \"--worktree\" flag to mean \"against the working tree\" then\nwe should start doing that also to `git status`, `git checkout`,\n`git blame`, and `git diff`.\n\n>  $ git describe --dirty v1.2.1\n> should it show an error, output \"v1.2.1\" anyway, or output\n> \"v1.2.1-dirty\" if the working tree is different from v1.2.1 ?\n\nIMHO, that should be a fatal usage error, if we go that approach.\nI would also argue `git describe --dirty HEAD` is equally fatal.\n\n-- \nShawn.\n"},{"id":"125215","messageId":"7vvdifq6vw.fsf@alter.siamese.dyndns.org","threadId":"21263","inReplyTo":"dffdbd190910161452o4ac0b426i7c48649eafa0d53@mail.gmail.com","subject":"Re: [PATCH RFC] git describe without refs distinguishes dirty working tree","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-10-16T23:02:59Z","receivedAt":"2009-10-16T23:02:59Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jean Privat <jean@pryen.org> writes:\n\n>> I still haven't heard anything that helps me to decide which way the\n>> default should be.  The only concrete thing I have heard against the\n>> change of the default is that it will break existing setup, but I haven't\n>> heard anything concrete for the change yet.\n>\n> As a said in the comment part of the initial message, I initially\n> planed to add a --worktree option that means \"I want you to describe\n> my working tree\". Knowing that from my naive point of view, the\n> description of the working tree is what build script wanted :\n> description of HEAD (on which is based the working tree) + saying that\n> if the working tree is dirty or not (done manually by scripts).\n> Moreover, in my naive view with the \"--worktree\" option, no refs where\n> allowed (i.e. describe the working tree xor describe some commit\n> references).\n\nI do not think it is naive at all.  \"git describe --worktree HEAD^\" won't\nmake any sense in that world view; by definition the work tree is not\nderived from anything but HEAD.\n\n> Then, I realized that for some other git commands that can work both\n> on the working tree and on an arbitrary commit reference, the default\n> was to work on the working tree and require an explicit HEAD to work\n> on the HEAD commit.\n\nBut the thing is, \"git describe\" without arguments already works on HEAD\nand describes it, and people depend on the behaviour.\n\nI originally thought this _might_ break and hoped it won't be a big issue,\nbut now I've seen that even the kernel would break (it runs the command\nwithout saying \"HEAD\"), I do not want to risk breaking other projects I\nmay not even heard of.  Some people might have copied our GIT-VERSION-GEN\n(that says \"HEAD\"), but I would not bet against that many many more people\nwould have copied the use of \"git describe\" from the kernel build tree\nthan from us.  After all, they are more famous and established than we\nare.  [*1*]\n\nOne line of argument that I would have found reasonable to defend the\nchange of the default is that \"The --worktree (or --dirty) option is\ncumbersome to type.  And in _this_ workflow (that I haven't imagined, but\nstill would be *very* valid and useful one---so anybody who argues along\nthis line needs to fill in the blank here), it is the best solution to ask\nthe \"git describe\" command about the state of the work tree from the\ncommand line very often, and here is why (here is another blank to fill\nin), because there is no other way to get at the information, and/or the\ninfo given by other existing commands are suboptimal for these reasons\n(here is another blank to fill in).\"\n\nThen we would need to weigh benefits (for the interactive use of a very\nuseful and often used form of the command) against downsides (for people\nhaving to update their existing scripts).\n\nFor use by scripts, the argument against having to give an extra option to\nget the new behaviour becomes much weaker than for interactive use, even\nif the new behaviour may be more common.  The point of scripting is that\nyou can write it once and forget about it; if it requires \"--worktree\" in\norder to omit an extra \"diff --index HEAD\", it is not such a big deal.\n\nAnd it is important to realize that \"can write it once and forget about\nit\" cuts both ways.  It should apply not only to the people who write\ntheir scripts after this patch of yours is applied to git, but should\nequally apply to the people who wrote their scripts long time ago,\nexpecting that they can safely forget about them once they wrote them,\nrelying on the existing behaviour of the command.  Changing the defaults\nfor them means we lied to them and they have to update their scripts.  In\nother words, they cannot script and forget about it anymore.\n\nAn attitude to change the default lightly like that, be it in 1.7.0 or\nnot, will then later come back and haunt your scripts you write while\nassuming that the behaviour your patch will bring in will stay forever.\nAllowing such a casual attitude will lead to other people changing the\ndefault equally casually in the future.\n\nIt is my job to say no, even when I 100% agree that the new behaviour\nwould have been the default one if we were inventing \"git describe\" from\nscratch and there were no existing users [*2*].  We do not live in an\nideal world, and 1.7.0 is not a blank check to change everything in sight.\n\n>> How about \"describe --dirty\" and \"describe --dirty=-mod\" (the latter\n>> creates v1.6.5-15-gc274db7-mod\")\n>\n> May be better than \"--wortree\" (especially because of the value part),\n> but what happen with\n>  $ git describe --dirty v1.2.1\n> should it show an error, output \"v1.2.1\" anyway, or output\n> \"v1.2.1-dirty\" if the working tree is different from v1.2.1 ?\n\nI am actually fine with your --worktree option, especially after seeing\nyour much more clear (i.e. \"the state of my work tree\") explanation in the\nbeginning of your response.\n\nBut I think \"git describe\" working in this \"describe the version in the\nwork tree in the point in history\" mode should reject any explicit\nrevision argument; by definition the work tree is not derived from\nanything but HEAD.\n\n\n[Footnote]\n\n*1* In addition to the \"it would break the kernel\" issue, there are some\nprojects that expect users to tweak files they ship before building\n(e.g. makefiles and config.h and the like).  For these people, any and all\nbuilds would be -dirty.  I expect these projects, when migrating to git,\nwould either update their build procedures (moving config.h to\nconfig.h-sample or something), but another solution for them would be to\nuse \"git describe\" without the -dirty bits.  So they are another class of\npeople who may not want -dirty by default.\n\n*2* It personally hurts in a case like this, but that is what maintainers\nhave to do.  The maintainer's job is not to be loved, but is largely to\nprotect existing users from the second system syndrome.\n"},{"id":"125222","messageId":"alpine.LFD.2.00.0910162028190.21739@xanadu.home","threadId":"21263","inReplyTo":"7vvdifq6vw.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH RFC] git describe without refs distinguishes dirty working tree","fromName":"Nicolas Pitre","fromEmail":"nico@fluxnic.net","sentAt":"2009-10-17T00:31:20Z","receivedAt":"2009-10-17T00:31:20Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Fri, 16 Oct 2009, Junio C Hamano wrote:\n\n> But the thing is, \"git describe\" without arguments already works on HEAD\n> and describes it, and people depend on the behaviour.\n> \n> I originally thought this _might_ break and hoped it won't be a big issue,\n> but now I've seen that even the kernel would break (it runs the command\n> without saying \"HEAD\"), I do not want to risk breaking other projects I\n> may not even heard of.  Some people might have copied our GIT-VERSION-GEN\n> (that says \"HEAD\"), but I would not bet against that many many more people\n> would have copied the use of \"git describe\" from the kernel build tree\n> than from us.\n\nOpenOCD is another project that just started using Git and copied \ndescribe usage from Linux.\n\n\nNicolas\n"}]}