{"thread":{"id":"12294","subject":"[PATCH] Teach git-describe --long to output always the long format","startedAt":"2008-02-24T14:46:52Z","lastAt":"2008-02-26T09:41:31Z","messageCount":12,"participants":["Santi Béjar","Shawn O. Pearce","Junio C Hamano","Jakub Narebski"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"69794","messageId":"1203864412-27977-1-git-send-email-sbejar@gmail.com","threadId":"12294","inReplyTo":null,"subject":"[PATCH] Teach git-describe --long to output always the long format","fromName":"Santi Béjar","fromEmail":"sbejar@gmail.com","sentAt":"2008-02-24T14:46:52Z","receivedAt":"2008-02-24T14:46:52Z","isPatch":true,"sender":{"key":"santi@agolina.net","avatar":null},"body":"Sometimes it is convenient to have the sha1 of a commit even\nif it matches a tag.\n\nSigned-off-by: Santi Béjar \n---\n builtin-describe.c | 11 ++++++++++-\n t/t6120-describe.sh | 2 ++\n 2 files changed, 12 insertions(+), 1 deletions(-)\n\ndiff --git a/builtin-describe.c b/builtin-describe.c\nindex 3428483..e46105a 100644\n--- a/builtin-describe.c\n+++ b/builtin-describe.c\n@@ -17,6 +17,7 @@ static const char * const describe_usage[] = {\n static int debug;\t/* Display lots of verbose info */\n static int all;\t/* Default to annotated tags only */\n static int tags;\t/* But allow any tags if --tags is specified */\n+static int longformat;\n static int abbrev = DEFAULT_ABBREV;\n static int max_candidates = 10;\n const char *pattern = NULL;\n@@ -155,7 +156,11 @@ static void describe(const char *arg, int last_one)\n \n \tn = cmit->util;\n \tif (n) {\n-\t\tprintf(\"%s\\n\", n->path);\n+\t\tif (!longformat)\n+\t\t\tprintf(\"%s\\n\", n->path );\n+\t\telse\n+\t\t\tprintf(\"%s-0-g%s\\n\", n->path,\n+\t\t\t\tfind_unique_abbrev(cmit->object.sha1, abbrev));\n \t\treturn;\n \t}\n \n@@ -254,6 +259,7 @@ int cmd_describe(int argc, const char **argv, const char *prefix)\n \t\tOPT_BOOLEAN(0, \"debug\", &debug, \"debug search strategy on stderr\"),\n \t\tOPT_BOOLEAN(0, \"all\", &all, \"use any ref in .git/refs\"),\n \t\tOPT_BOOLEAN(0, \"tags\", &tags, \"use any tag in .git/refs/tags\"),\n+\t\tOPT_BOOLEAN(0, \"long\", &longformat, \"always use long format\"),\n \t\tOPT__ABBREV(&abbrev),\n \t\tOPT_INTEGER(0, \"candidates\", &max_candidates,\n \t\t\t \"consider most recent tags (default: 10)\"),\n@@ -270,6 +276,9 @@ int cmd_describe(int argc, const char **argv, const char *prefix)\n \n \tsave_commit_buffer = 0;\n \n+\tif (longformat && abbrev == 0)\n+\t\tdie(\"--long is incompatible with --abbrev=0\");\n+\n \tif (contains) {\n \t\tconst char **args = xmalloc((6 + argc) * sizeof(char*));\n \t\tint i = 0;\ndiff --git a/t/t6120-describe.sh b/t/t6120-describe.sh\nindex ae8ee11..a7557bd 100755\n--- a/t/t6120-describe.sh\n+++ b/t/t6120-describe.sh\n@@ -94,4 +94,6 @@ check_describe D-* --tags HEAD^^\n check_describe A-* --tags HEAD^^2\n check_describe B --tags HEAD^^2^\n \n+check_describe B-0-* --long HEAD^^2^\n+\n test_done\n-- \n1.5.4.3.293.gac81\n"},{"id":"69840","messageId":"20080225023634.GK8410@spearce.org","threadId":"12294","inReplyTo":"1203864412-27977-1-git-send-email-sbejar@gmail.com","subject":"Re: [PATCH] Teach git-describe --long to output always the long format","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2008-02-25T02:36:34Z","receivedAt":"2008-02-25T02:36:34Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Santi Bjar wrote:\n> @@ -155,7 +156,11 @@ static void describe(const char *arg, int last_one)\n> \n> \tn = cmit->util;\n> \tif (n) {\n> -\t\tprintf(\"%s\\n\", n->path);\n> +\t\tif (!longformat)\n> +\t\t\tprintf(\"%s\\n\", n->path );\n\nExtra whitespace after the \"path\".\n\n> +\t\telse\n> +\t\t\tprintf(\"%s-0-g%s\\n\", n->path,\n> +\t\t\t\tfind_unique_abbrev(cmit->object.sha1, abbrev));\n\nIs this really that useful? Where is having the tag and the commit\nSHA-1 both useful?\n\n> \t\treturn;\n> \t}\n> \n> @@ -254,6 +259,7 @@ int cmd_describe(int argc, const char **argv, const char *prefix)\n> \t\tOPT_BOOLEAN(0, \"debug\", &debug, \"debug search strategy on stderr\"),\n> \t\tOPT_BOOLEAN(0, \"all\", &all, \"use any ref in .git/refs\"),\n> \t\tOPT_BOOLEAN(0, \"tags\", &tags, \"use any tag in .git/refs/tags\"),\n> +\t\tOPT_BOOLEAN(0, \"long\", &longformat, \"always use long format\"),\n\nDocumentation?\n\n-- \nShawn.\n"},{"id":"69842","messageId":"7vwsotpwbr.fsf@gitster.siamese.dyndns.org","threadId":"12294","inReplyTo":"20080225023634.GK8410@spearce.org","subject":"Re: [PATCH] Teach git-describe --long to output always the long format","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-02-25T03:08:08Z","receivedAt":"2008-02-25T03:08:08Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Shawn O. Pearce\" writes:\n\n>> +\t\telse\n>> +\t\t\tprintf(\"%s-0-g%s\\n\", n->path,\n>> +\t\t\t\tfind_unique_abbrev(cmit->object.sha1, abbrev));\n>\n> Is this really that useful? Where is having the tag and the commit\n> SHA-1 both useful?\n\nI had the same question. The only place that I find this could\nbe useful is when you tag, build and install, and then find\nglitches before pushing the results out and rewind, rebuild and\nre-tag. I unfortunately have this issue almost all the time.\n\nBut even then, I would probably not rely on this patch.\n"},{"id":"69868","messageId":"8aa486160802250034ncdf20b6s13856ca8612bc2ea@mail.gmail.com","threadId":"12294","inReplyTo":"7vwsotpwbr.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] Teach git-describe --long to output always the long format","fromName":"Santi Béjar","fromEmail":"sbejar@gmail.com","sentAt":"2008-02-25T08:34:31Z","receivedAt":"2008-02-25T08:34:31Z","isPatch":true,"sender":{"key":"santi@agolina.net","avatar":null},"body":"On Mon, Feb 25, 2008 at 4:08 AM, Junio C Hamano wrote:\n> \"Shawn O. Pearce\" writes:\n>\n> >> + else\n> >> + printf(\"%s-0-g%s\\n\", n->path,\n> >> + find_unique_abbrev(cmit->object.sha1, abbrev));\n> >\n> > Is this really that useful? Where is having the tag and the commit\n> > SHA-1 both useful?\n>\n> I had the same question. The only place that I find this could\n> be useful is when you tag, build and install, and then find\n> glitches before pushing the results out and rewind, rebuild and\n> re-tag. I unfortunately have this issue almost all the time.\n>\n> But even then, I would probably not rely on this patch.\n>\n\nThis can be usefull when more than one person can make \"official\" tags\n(or nobody), and then you have a uniqe idendifier with a descriptive\nname.\n\nSanti\n"},{"id":"69872","messageId":"m3oda5betk.fsf@localhost.localdomain","threadId":"12294","inReplyTo":"7vwsotpwbr.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] Teach git-describe --long to output always the long format","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-02-25T08:50:06Z","receivedAt":"2008-02-25T08:50:06Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano writes:\n\n> \"Shawn O. Pearce\" writes:\n> \n>>> +\t\telse\n>>> +\t\t\tprintf(\"%s-0-g%s\\n\", n->path,\n>>> +\t\t\t\tfind_unique_abbrev(cmit->object.sha1, abbrev));\n>>\n>> Is this really that useful? Where is having the tag and the commit\n>> SHA-1 both useful?\n> \n> I had the same question. The only place that I find this could\n> be useful is when you tag, build and install, and then find\n> glitches before pushing the results out and rewind, rebuild and\n> re-tag. I unfortunately have this issue almost all the time.\n\nAnother place where it is useful is parsing git-describe output, for\nexample in .spec file for RPM, if you want to avoid hardcoding the\ninformation about the form of tags in a project (tags can, and\nsometimes do, contain '-'). If you always use --long form, it is easy\nto separate number of commits from tag and shortened sha1 from the tag\nitself, for example to put closest tag as version number, and make\nnumber of commits and perhaps also shortened sha1 into release number.\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"69874","messageId":"7vbq65ju0y.fsf@gitster.siamese.dyndns.org","threadId":"12294","inReplyTo":"8aa486160802250034ncdf20b6s13856ca8612bc2ea@mail.gmail.com","subject":"Re: [PATCH] Teach git-describe --long to output always the long format","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-02-25T08:54:21Z","receivedAt":"2008-02-25T08:54:21Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Santi Béjar\" writes:\n\n> On Mon, Feb 25, 2008 at 4:08 AM, Junio C Hamano wrote:\n>> \"Shawn O. Pearce\" writes:\n>> ...\n>> > Is this really that useful? Where is having the tag and the commit\n>> > SHA-1 both useful?\n>>\n>> I had the same question. The only place that I find this could\n>> be useful is when you tag, build and install, and then find\n>> glitches before pushing the results out and rewind, rebuild and\n>> re-tag. I unfortunately have this issue almost all the time.\n>>\n>> But even then, I would probably not rely on this patch.\n>\n> This can be usefull when more than one person can make \"official\" tags\n> (or nobody), and then you have a uniqe idendifier with a descriptive\n> name.\n\nThat's backwards. If you want reliable unique identifier, you\nwould use 40-hexdigit. If you want human readable, you would\nuse tags, and if you allow different people to distribute tags\nwith the same name that point at different things, _you_ have a\nproblem at higher level.\n\nBy the way, I think the naming \"git describe\" does is not quite\nright. The name of the tag _usually_ matches its path under\nrefs/tags/ by convention, but the code seems to trust the path\nand does not seem to examine what the actual tag name in the\nannotated tag is.\n\nI think it should name commits based on the real tag name, at\nleast when it is only using annotated tags (i.e. the default\nmode of operation).\n"},{"id":"69875","messageId":"8aa486160802250105p4f98cb6eu1d6ac4fa700f11fe@mail.gmail.com","threadId":"12294","inReplyTo":"7vbq65ju0y.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] Teach git-describe --long to output always the long format","fromName":"Santi Béjar","fromEmail":"sbejar@gmail.com","sentAt":"2008-02-25T09:05:55Z","receivedAt":"2008-02-25T09:05:55Z","isPatch":true,"sender":{"key":"santi@agolina.net","avatar":null},"body":"On Mon, Feb 25, 2008 at 9:54 AM, Junio C Hamano wrote:\n> \"Santi Béjar\" writes:\n>\n> > On Mon, Feb 25, 2008 at 4:08 AM, Junio C Hamano wrote:\n> >> \"Shawn O. Pearce\" writes:\n> >> ...\n>\n> >> > Is this really that useful? Where is having the tag and the commit\n> >> > SHA-1 both useful?\n> >>\n> >> I had the same question. The only place that I find this could\n> >> be useful is when you tag, build and install, and then find\n> >> glitches before pushing the results out and rewind, rebuild and\n> >> re-tag. I unfortunately have this issue almost all the time.\n> >>\n> >> But even then, I would probably not rely on this patch.\n> >\n> > This can be usefull when more than one person can make \"official\" tags\n> > (or nobody), and then you have a uniqe idendifier with a descriptive\n> > name.\n>\n> That's backwards. If you want reliable unique identifier, you\n> would use 40-hexdigit. If you want human readable, you would\n> use tags, and if you allow different people to distribute tags\n> with the same name that point at different things, _you_ have a\n> problem at higher level.\n\nYes, I have a \"problem\" at a higher level, but I cannot \"solve\" it.\nThis patch \"workaround\" this \"problem\", we want all to be able to tag\nand have descriptive and uniqe names. I think git should allows us to\nwork this way.\n\nSanti\n"},{"id":"69876","messageId":"1203932613-7759-1-git-send-email-sbejar@gmail.com","threadId":"12294","inReplyTo":"1203864412-27977-1-git-send-email-sbejar@gmail.com","subject":"[PATCH] Teach git-describe --long to output always the long format","fromName":"Santi Béjar","fromEmail":"sbejar@gmail.com","sentAt":"2008-02-25T09:43:33Z","receivedAt":"2008-02-25T09:43:33Z","isPatch":true,"sender":{"key":"santi@agolina.net","avatar":null},"body":"This can be useful when more than one person can make \"official\" tags\n(or nobody), but you want unique identifiers with a descriptive\nname. Or when parsing git-describe output if you want to avoid\nhardcoding the information about the form of tags in a project\n(tags can, and sometimes do, contain '-').\n\nSigned-off-by: Santi Béjar \n---\nHi,\n\n this time with documentation and usecases (thanks Jakub)\n\nSanti\n\n Documentation/git-describe.txt | 9 +++++++++\n builtin-describe.c | 11 ++++++++++-\n t/t6120-describe.sh | 2 ++\n 3 files changed, 21 insertions(+), 1 deletions(-)\n\ndiff --git a/Documentation/git-describe.txt b/Documentation/git-describe.txt\nindex 1c3dfb4..f46fbdd 100644\n--- a/Documentation/git-describe.txt\n+++ b/Documentation/git-describe.txt\n@@ -51,6 +51,15 @@ OPTIONS\n \tbeing employed to standard error. The tag name will still\n \tbe printed to standard out.\n \n+--long::\n+\tAlways output the long format (the tag, the number of commits\n+\tand the abbreviated commit name) even when it matches a tag.\n+\tThis can be useful when more than one person can make \"official\" tags\n+\t(or nobody), but you want unique identifiers with a descriptive\n+\tname. Or when parsing git-describe output if you want to avoid\n+\thardcoding the information about the form of tags in a project\n+\t(tags can, and sometimes do, contain '-').\n+\n --match ::\n \tOnly consider tags matching the given pattern (can be used to avoid\n \tleaking private tags made from the repository).\ndiff --git a/builtin-describe.c b/builtin-describe.c\nindex 3428483..3fd2e73 100644\n--- a/builtin-describe.c\n+++ b/builtin-describe.c\n@@ -17,6 +17,7 @@ static const char * const describe_usage[] = {\n static int debug;\t/* Display lots of verbose info */\n static int all;\t/* Default to annotated tags only */\n static int tags;\t/* But allow any tags if --tags is specified */\n+static int longformat;\n static int abbrev = DEFAULT_ABBREV;\n static int max_candidates = 10;\n const char *pattern = NULL;\n@@ -155,7 +156,11 @@ static void describe(const char *arg, int last_one)\n \n \tn = cmit->util;\n \tif (n) {\n-\t\tprintf(\"%s\\n\", n->path);\n+\t\tif (!longformat)\n+\t\t\tprintf(\"%s\\n\", n->path);\n+\t\telse\n+\t\t\tprintf(\"%s-0-g%s\\n\", n->path,\n+\t\t\t\tfind_unique_abbrev(cmit->object.sha1, abbrev));\n \t\treturn;\n \t}\n \n@@ -254,6 +259,7 @@ int cmd_describe(int argc, const char **argv, const char *prefix)\n \t\tOPT_BOOLEAN(0, \"debug\", &debug, \"debug search strategy on stderr\"),\n \t\tOPT_BOOLEAN(0, \"all\", &all, \"use any ref in .git/refs\"),\n \t\tOPT_BOOLEAN(0, \"tags\", &tags, \"use any tag in .git/refs/tags\"),\n+\t\tOPT_BOOLEAN(0, \"long\", &longformat, \"always use long format\"),\n \t\tOPT__ABBREV(&abbrev),\n \t\tOPT_INTEGER(0, \"candidates\", &max_candidates,\n \t\t\t \"consider most recent tags (default: 10)\"),\n@@ -270,6 +276,9 @@ int cmd_describe(int argc, const char **argv, const char *prefix)\n \n \tsave_commit_buffer = 0;\n \n+\tif (longformat && abbrev == 0)\n+\t\tdie(\"--long is incompatible with --abbrev=0\");\n+\n \tif (contains) {\n \t\tconst char **args = xmalloc((6 + argc) * sizeof(char*));\n \t\tint i = 0;\ndiff --git a/t/t6120-describe.sh b/t/t6120-describe.sh\nindex ae8ee11..a7557bd 100755\n--- a/t/t6120-describe.sh\n+++ b/t/t6120-describe.sh\n@@ -94,4 +94,6 @@ check_describe D-* --tags HEAD^^\n check_describe A-* --tags HEAD^^2\n check_describe B --tags HEAD^^2^\n \n+check_describe B-0-* --long HEAD^^2^\n+\n test_done\n-- \n1.5.4.3.293.gac81\n"},{"id":"69917","messageId":"7vwsoshk3s.fsf@gitster.siamese.dyndns.org","threadId":"12294","inReplyTo":"8aa486160802250105p4f98cb6eu1d6ac4fa700f11fe@mail.gmail.com","subject":"Re: [PATCH] Teach git-describe --long to output always the long format","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-02-25T20:11:35Z","receivedAt":"2008-02-25T20:11:35Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Santi Béjar\" writes:\n\n>> That's backwards. If you want reliable unique identifier, you\n>> would use 40-hexdigit. If you want human readable, you would\n>> use tags, and if you allow different people to distribute tags\n>> with the same name that point at different things, _you_ have a\n>> problem at higher level.\n>\n> Yes, I have a \"problem\" at a higher level, but I cannot \"solve\" it.\n> This patch \"workaround\" this \"problem\", we want all to be able to tag\n> and have descriptive and uniqe names. I think git should allows us to\n> work this way.\n\nWhy can't you solve it? Your example of two people giving the\nsame name to different things shows a lack of communication\nbetween developers, and as long as you and the other guy are\ntalking with each other the problem can be solved, can't it?\n\nSCM or any other tools may facilitate developer communication,\nbut it is not a replacement for communication.\n\nInside a local repository, git already allows you to:\n\n * prevent such a problem by not overwriting an existing tag\n unless you ask with -f; and\n\n * verify that the object a tag refers to is really the object\n you expect the tag to point at with \"cat-file tag\".\n\n\"git describe\" output can be unique only within a local\nrepository, as it cannot read your mind and inspect random\nrepositories other people own. In one repository, abbreviating\nan object name to 4 hexdigits may be enough to make it unique,\nbut in another it may need 6 hexdigits.\n\nIf you are trying to guarantee uniqueness of something that\nlives for a long time (e.g. release version number that is\nembedded inside binaries, which is what you use \"git describe\"\nto generate), _and_ if you worry about two people in different\nrepositories giving the same name to different things which\nwould introduce a bogosity to that long-lived name, you would\nneed a way that is external to the uniqueness guarantee \"git\ndescribe\" can give.\n\nI do not mind low-impact new options and new features like this.\nEverybody loves bells and whistles. But I do want valid use\ncases attached to them so that (1) we can justify their\nexistence; and (2) we can document them to explain what purpose\nthey serve, to help people to decide when to use them.\n\nI even suspect that the --long flag might be useful in some\nsituation, but I do not think \"a tag with the same name\" is one\nof the problems this patch lets you solve or work around.\n\nJakub's \"it looks more uniform and does not treat a tagged\nversion any specially\" may probably be a better argument for\nthis new feature. I dunno.\n"},{"id":"69923","messageId":"8aa486160802251251u74a19b93l77ca3930d2387cb8@mail.gmail.com","threadId":"12294","inReplyTo":"7vwsoshk3s.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] Teach git-describe --long to output always the long format","fromName":"Santi Béjar","fromEmail":"sbejar@gmail.com","sentAt":"2008-02-25T20:51:02Z","receivedAt":"2008-02-25T20:51:02Z","isPatch":true,"sender":{"key":"santi@agolina.net","avatar":null},"body":"On Mon, Feb 25, 2008 at 9:11 PM, Junio C Hamano wrote:\n> \"Santi Béjar\" writes:\n>\n>\n> >> That's backwards. If you want reliable unique identifier, you\n> >> would use 40-hexdigit. If you want human readable, you would\n> >> use tags, and if you allow different people to distribute tags\n> >> with the same name that point at different things, _you_ have a\n> >> problem at higher level.\n> >\n> > Yes, I have a \"problem\" at a higher level, but I cannot \"solve\" it.\n> > This patch \"workaround\" this \"problem\", we want all to be able to tag\n> > and have descriptive and uniqe names. I think git should allows us to\n> > work this way.\n>\n> Why can't you solve it? Your example of two people giving the\n> same name to different things shows a lack of communication\n> between developers, and as long as you and the other guy are\n> talking with each other the problem can be solved, can't it?\n\nBut there are times when you can't/don't want to communicate\n(private/testing/forks, whatever).\n\nAnyway, even if this problem is solved I feel more confortable with a version in\nmy binary (and output) with a descriptive name and a revision id.\n\n> SCM or any other tools may facilitate developer communication,\n> but it is not a replacement for communication.\n\nI know, but my problem is not lack of communication.\n\n>\n> \"git describe\" output can be unique only within a local\n> repository, as it cannot read your mind and inspect random\n> repositories other people own. In one repository, abbreviating\n> an object name to 4 hexdigits may be enough to make it unique,\n> but in another it may need 6 hexdigits.\n\nIf you always use \"git describe --long\" it is globally unique, as long as sha1\nis globally unique (at least unique enough).\n\n> If you are trying to guarantee uniqueness of something that\n> lives for a long time (e.g. release version number that is\n> embedded inside binaries, which is what you use \"git describe\"\n> to generate), _and_ if you worry about two people in different\n> repositories giving the same name to different things which\n> would introduce a bogosity to that long-lived name, you would\n> need a way that is external to the uniqueness guarantee \"git\n> describe\" can give.\n\nSee above.\n\n> I do not mind low-impact new options and new features like this.\n> Everybody loves bells and whistles. But I do want valid use\n> cases attached to them so that (1) we can justify their\n> existence; and (2) we can document them to explain what purpose\n> they serve, to help people to decide when to use them.\n\nOK.\n\n> I even suspect that the --long flag might be useful in some\n> situation, but I do not think \"a tag with the same name\" is one\n> of the problems this patch lets you solve or work around.\n>\n> Jakub's \"it looks more uniform and does not treat a tagged\n> version any specially\" may probably be a better argument for\n> this new feature. I dunno.\n>\n\nMaybe.\n\nSanti\n"},{"id":"69968","messageId":"7vy7986pnc.fsf@gitster.siamese.dyndns.org","threadId":"12294","inReplyTo":"8aa486160802251251u74a19b93l77ca3930d2387cb8@mail.gmail.com","subject":"Re: [PATCH] Teach git-describe --long to output always the long format","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-02-26T09:19:35Z","receivedAt":"2008-02-26T09:19:35Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Santi Béjar\" writes:\n\n>> Why can't you solve it? Your example of two people giving the\n>> same name to different things shows a lack of communication\n>> between developers, and as long as you and the other guy are\n>> talking with each other the problem can be solved, can't it?\n>\n> But there are times when you can't/don't want to communicate\n> (private/testing/forks, whatever).\n>\n> Anyway, even if this problem is solved I feel more confortable\n> with a version in my binary (and output) with a descriptive\n> name and a revision id.\n\nAs I think about it more, I think that such a lack of communication is\nnot something \"git describe\" should even claim to help working around.\n\nBut a uniform-looking describe output does have certain\nattractiveness:\n\n\t$ git describe --long 31e0b2c 6c0f869\n v1.5.4.3-0-g31e0b2c\n v1.5.4.3-1-g6c0f869\n\nSo I have quite a big problem with your commit log message, even\nthough I am starting to like what it does. Perhaps this would be more\nto the point.\n\n git-describe: --long shows the object name even for a tagged commit\n \n This is useful when you want to see parts of the commit object name\n in \"describe\" output, even when the commit in question happens to be\n a tagged version. Instead of just emitting the tag name, it will\n describe such a commit as v1.2-0-deadbeef (0th commit since tag v1.2\n that points at object deadbeef....).\n\nBy the way, I do not think \"long\" is what it does. It does not even\nshow the full object name unless you tell it to with another option\n(i.e. --abbrev). The flag tells the command to use the normal output\nformat that is used to describe most other commits (untagged ones),\nand signal the \"taggedness\" with the count part being \"-0-\".\n\nPerhaps --nonexact-format, or even --redundant-output?\n\nHmmmmm... \"--always-count\", as it is about always using the counted\nformat (which is the \"normal\" output format)?\n\nI know, I am bad at naming, so I'll park the commit in 'pu',\nwith option name kept as \"--long\" as in your patch.\n"},{"id":"69974","messageId":"8aa486160802260141i62c33f02kcc641936ac9116e5@mail.gmail.com","threadId":"12294","inReplyTo":"7vy7986pnc.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] Teach git-describe --long to output always the long format","fromName":"Santi Béjar","fromEmail":"sbejar@gmail.com","sentAt":"2008-02-26T09:41:31Z","receivedAt":"2008-02-26T09:41:31Z","isPatch":true,"sender":{"key":"santi@agolina.net","avatar":null},"body":"On Tue, Feb 26, 2008 at 10:19 AM, Junio C Hamano wrote:\n> \"Santi Béjar\" writes:\n>\n> So I have quite a big problem with your commit log message, even\n> though I am starting to like what it does. Perhaps this would be more\n> to the point.\n>\n> git-describe: --long shows the object name even for a tagged commit\n>\n> This is useful when you want to see parts of the commit object name\n> in \"describe\" output, even when the commit in question happens to be\n> a tagged version. Instead of just emitting the tag name, it will\n> describe such a commit as v1.2-0-deadbeef (0th commit since tag v1.2\n> that points at object deadbeef....).\n>\n\nI think it's find, and to the point. Thanks.\n\n> By the way, I do not think \"long\" is what it does. It does not even\n> show the full object name unless you tell it to with another option\n> (i.e. --abbrev). The flag tells the command to use the normal output\n> format that is used to describe most other commits (untagged ones),\n> and signal the \"taggedness\" with the count part being \"-0-\".\n>\n> Perhaps --nonexact-format, or even --redundant-output?\n>\n> Hmmmmm... \"--always-count\", as it is about always using the counted\n> format (which is the \"normal\" output format)?\n\nI call it --long for longformat, maybe --longformat, --always-long,\n--always-normal.\n\n>\n> I know, I am bad at naming, so I'll park the commit in 'pu',\n> with option name kept as \"--long\" as in your patch.\n\nMe too.\n\nSanti\n"}]}