{"thread":{"id":"43107","subject":"Re: Suggestion: drop 'g' in git-describe suffix","startedAt":"2006-11-02T01:23:04Z","lastAt":"2006-11-02T19:12:55Z","messageCount":19,"participants":["Jakub Narebski","Santi Béjar","Petr Baudis","Nicolas Vilz 'niv'","Han-Wen Nienhuys","Johannes Schindelin","Andy Whitcroft","Carl Worth"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"294549","messageId":"eibh94$t7n$1@sea.gmane.org","threadId":"43107","inReplyTo":null,"subject":"Suggestion: drop 'g' in git-describe suffix","fromName":"Han-Wen Nienhuys","fromEmail":"hanwen@xs4all.nl","sentAt":"2006-11-02T01:23:04Z","receivedAt":"2006-11-02T01:23:04Z","isPatch":false,"sender":{"key":"hanwen@google.com","avatar":"https://avatars.githubusercontent.com/u/31547?v=4"},"body":"\nhi,\n\nthe convention to use a 'g' in the output of git-describe, eg.\n\n [lilydev@haring lilypond]$ git describe --abbrev=39\n lilypond_2_9_7-g47778d2297276484c861fc7536da13feb2d5fe8\n\n\nis confusing: the g is also a hex digit, and without reading the manual \ncarefully, you'd think this is the commit g4777.\n\nProposal: why not use\n\n tag#sha1\n\nor some other non-hex character.\n\n-- \n Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen\n"},{"id":"298199","messageId":"45494E20.1000503@shadowen.org","threadId":"43107","inReplyTo":"eibh94$t7n$1@sea.gmane.org","subject":"Re: Suggestion: drop 'g' in git-describe suffix","fromName":"Andy Whitcroft","fromEmail":"apw@shadowen.org","sentAt":"2006-11-02T01:47:12Z","receivedAt":"2006-11-02T01:47:12Z","isPatch":false,"sender":{"key":"apw@shadowen.org","avatar":"https://gravatar.com/avatar/d3088262854661a913ef35cc40fedcc270142d4461791142bc1ea0b2a4e2e147?d=mp&s=160"},"body":"Han-Wen Nienhuys wrote:\n> \n> hi,\n> \n> the convention to use a 'g' in the output of git-describe, eg.\n> \n> [lilydev@haring lilypond]$ git describe --abbrev=39\n> lilypond_2_9_7-g47778d2297276484c861fc7536da13feb2d5fe8\n> \n> \n> is confusing: the g is also a hex digit, and without reading the manual\n> carefully, you'd think this is the commit g4777.\n> \n> Proposal: why not use\n> \n> tag#sha1\n> \n> or some other non-hex character.\n\ng is not a hex digit, hex is 0-f ??\n\nIn current versions of git, this whole string is also a valid name for\nthe commit ie you can do the following:\n\n\tgit show lilypond_2_9_7-g47778d2297276484c861fc7536da13feb2d5fe8\n\n-apw\n"},{"id":"296335","messageId":"4549C083.9060805@xs4all.nl","threadId":"43107","inReplyTo":"45494E20.1000503@shadowen.org","subject":"Re: Suggestion: drop 'g' in git-describe suffix","fromName":"Han-Wen Nienhuys","fromEmail":"hanwen@xs4all.nl","sentAt":"2006-11-02T09:55:15Z","receivedAt":"2006-11-02T09:55:15Z","isPatch":false,"sender":{"key":"hanwen@google.com","avatar":"https://avatars.githubusercontent.com/u/31547?v=4"},"body":"Andy Whitcroft escreveu:\n>> or some other non-hex character.\n> \n> g is not a hex digit, hex is 0-f ??\n> \n\nYes of course; silly me. Still I think it would be clearer if it used a \nnon-alphabet char, eg.\n\n tag+sha1\n\nto separate the tag and the committish.\n\n-- \n Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen\n"},{"id":"297335","messageId":"4549CA6B.4090909@shadowen.org","threadId":"43107","inReplyTo":"4549C083.9060805@xs4all.nl","subject":"Re: Suggestion: drop 'g' in git-describe suffix","fromName":"Andy Whitcroft","fromEmail":"apw@shadowen.org","sentAt":"2006-11-02T10:37:31Z","receivedAt":"2006-11-02T10:37:31Z","isPatch":false,"sender":{"key":"apw@shadowen.org","avatar":"https://gravatar.com/avatar/d3088262854661a913ef35cc40fedcc270142d4461791142bc1ea0b2a4e2e147?d=mp&s=160"},"body":"Han-Wen Nienhuys wrote:\n> Andy Whitcroft escreveu:\n>>> or some other non-hex character.\n>>\n>> g is not a hex digit, hex is 0-f ??\n>>\n> \n> Yes of course; silly me. Still I think it would be clearer if it used a\n> non-alphabet char, eg.\n> \n> tag+sha1\n> \n> to separate the tag and the committish.\n\nWell there is a non-alphabet character in there, a minus (-). The g\nprefix on the sha1 _fragment_ it to indicate that it is in fact a\ntruncated sha1, not a complete one. If you want the complete clean sha1\nthis is not the way to get it?\n\n"},{"id":"298531","messageId":"4549CE2A.3010808@xs4all.nl","threadId":"43107","inReplyTo":"4549CA6B.4090909@shadowen.org","subject":"Re: Suggestion: drop 'g' in git-describe suffix","fromName":"Han-Wen Nienhuys","fromEmail":"hanwen@xs4all.nl","sentAt":"2006-11-02T10:53:30Z","receivedAt":"2006-11-02T10:53:30Z","isPatch":false,"sender":{"key":"hanwen@google.com","avatar":"https://avatars.githubusercontent.com/u/31547?v=4"},"body":"Andy Whitcroft escreveu:\n> Han-Wen Nienhuys wrote:\n>> Andy Whitcroft escreveu:\n>>>> or some other non-hex character.\n>>> g is not a hex digit, hex is 0-f ??\n>>>\n>> Yes of course; silly me. Still I think it would be clearer if it used a\n>> non-alphabet char, eg.\n>>\n>> tag+sha1\n>>\n>> to separate the tag and the committish.\n> \n> Well there is a non-alphabet character in there, a minus (-). The g\n> prefix on the sha1 _fragment_ it to indicate that it is in fact a\n> truncated sha1, not a complete one. \n\nis this policy documented somewhere? None of the tools understand it.\n\n[lilydev@haring git]$ git describe\nv1.4.3.3-g1e1f76e\n[lilydev@haring git]$ git show g1e1f76e\nfatal: ambiguous argument 'g1e1f76e': unknown revision or path not in \nthe working tree.\nUse '--' to separate paths from revisions\n\nMy suggestion is to use\n\n v1.4.3.3+1e1f76e\n\nhere.\n\n> If you want the complete clean sha1\n> this is not the way to get it?\n\n\n-- \n Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen\n"},{"id":"297658","messageId":"Pine.LNX.4.63.0611021158430.1670@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"43107","inReplyTo":"4549CE2A.3010808@xs4all.nl","subject":"Re: Suggestion: drop 'g' in git-describe suffix","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-11-02T10:59:12Z","receivedAt":"2006-11-02T10:59:12Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 2 Nov 2006, Han-Wen Nienhuys wrote:\n\n> [lilydev@haring git]$ git describe\n> v1.4.3.3-g1e1f76e\n> [lilydev@haring git]$ git show g1e1f76e\n\nYou'd want to do\n\n\tgit show v1.4.3.3-g1e1f76e\n\nHth,\n"},{"id":"294311","messageId":"20061102110331.GJ20017@pasky.or.cz","threadId":"43107","inReplyTo":"4549CA6B.4090909@shadowen.org","subject":"Re: Suggestion: drop 'g' in git-describe suffix","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-11-02T11:03:31Z","receivedAt":"2006-11-02T11:03:31Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Thu, Nov 02, 2006 at 11:37:31AM CET, I got a letter\nwhere Andy Whitcroft said that...\n> The g prefix on the sha1 _fragment_ it to indicate that it is in fact\n> a truncated sha1, not a complete one.\n\nI think it's rather to indicate that it is a sha1 at all.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\n#!/bin/perl -sp0777i wrote:\n> Andy Whitcroft escreveu:\n> > Han-Wen Nienhuys wrote:\n> >>\n> >> tag+sha1\n> >>\n> >> to separate the tag and the committish.\n> >\n> > Well there is a non-alphabet character in there, a minus (-). The g\n> > prefix on the sha1 _fragment_ it to indicate that it is in fact a\n> > truncated sha1, not a complete one.\n\nI think it is there to indicate it is a git commit sha1.\n\n>\n> is this policy documented somewhere? None of the tools understand it.\n>\n> [lilydev@haring git]$ git describe\n> v1.4.3.3-g1e1f76e\n> [lilydev@haring git]$ git show g1e1f76e\n> fatal: ambiguous argument 'g1e1f76e': unknown revision or path not in\n> the working tree.\n> Use '--' to separate paths from revisions\n>\n\nUse the complete output of describe:\n$ git show v1.4.3.3-g1e1f76e\n\nor the abbrev sha1:\n$ git show 1e1f76e\n\n> My suggestion is to use\n>\n> v1.4.3.3+1e1f76e\n\nMy suggestion is to use:\n\nv1.4.3.3-git1e1f76e\n\nto make clear that it is a git revision version.\n\nOne problem I see with this scheme (either 'g', 'git' of '+') is that\nit does not provide an increasing version number, even for\nfast-forwarding commits. Then it is not useful as a package version\nnumber (deb or rpm). I've already seen deb packages with\nversion+git20061010. One possibility could be to add the number of\ncommits between the tag and the commit as:\n\nv1.4.3.3-git12g1e1f76e\n\nto provide a weak ordering for fast-forwarding commits. What do you thing?\n\n"},{"id":"295467","messageId":"4549D2A7.7000209@shadowen.org","threadId":"43107","inReplyTo":"4549CE2A.3010808@xs4all.nl","subject":"Re: Suggestion: drop 'g' in git-describe suffix","fromName":"Andy Whitcroft","fromEmail":"apw@shadowen.org","sentAt":"2006-11-02T11:12:39Z","receivedAt":"2006-11-02T11:12:39Z","isPatch":false,"sender":{"key":"apw@shadowen.org","avatar":"https://gravatar.com/avatar/d3088262854661a913ef35cc40fedcc270142d4461791142bc1ea0b2a4e2e147?d=mp&s=160"},"body":"Han-Wen Nienhuys wrote:\n> Andy Whitcroft escreveu:\n>> Han-Wen Nienhuys wrote:\n>>> Andy Whitcroft escreveu:\n>>>>> or some other non-hex character.\n>>>> g is not a hex digit, hex is 0-f ??\n>>>>\n>>> Yes of course; silly me. Still I think it would be clearer if it used a\n>>> non-alphabet char, eg.\n>>>\n>>> tag+sha1\n>>>\n>>> to separate the tag and the committish.\n>>\n>> Well there is a non-alphabet character in there, a minus (-). The g\n>> prefix on the sha1 _fragment_ it to indicate that it is in fact a\n>> truncated sha1, not a complete one. \n> \n> is this policy documented somewhere? None of the tools understand it.\n> \n> [lilydev@haring git]$ git describe\n> v1.4.3.3-g1e1f76e\n> [lilydev@haring git]$ git show g1e1f76e\n> fatal: ambiguous argument 'g1e1f76e': unknown revision or path not in\n> the working tree.\n> Use '--' to separate paths from revisions\n> \n> My suggestion is to use\n> \n> v1.4.3.3+1e1f76e\n> \n> here.\n\nThe 'whole' thing is valid as an object reference:\n\napw@pinky$ git describe\nv1.4.3.3-g8cf249b\napw@pinky$ git show v1.4.3.3-g8cf249b\ncommit 8cf249b755c257ea19100b888ac612e601cdf96b\nMerge: 15c3ffb... fa438a2...\n[...]\n\n"},{"id":"296308","messageId":"4549D4B4.4030601@shadowen.org","threadId":"43107","inReplyTo":"8aa486160611020312v42047716t6a13e6fa16eeae8@mail.gmail.com","subject":"Re: Suggestion: drop 'g' in git-describe suffix","fromName":"Andy Whitcroft","fromEmail":"apw@shadowen.org","sentAt":"2006-11-02T11:21:24Z","receivedAt":"2006-11-02T11:21:24Z","isPatch":false,"sender":{"key":"apw@shadowen.org","avatar":"https://gravatar.com/avatar/d3088262854661a913ef35cc40fedcc270142d4461791142bc1ea0b2a4e2e147?d=mp&s=160"},"body":"Santi Béjar wrote:\n> On 11/2/06, Han-Wen Nienhuys wrote:\n>> Andy Whitcroft escreveu:\n>> > Han-Wen Nienhuys wrote:\n>> >>\n>> >> tag+sha1\n>> >>\n>> >> to separate the tag and the committish.\n>> >\n>> > Well there is a non-alphabet character in there, a minus (-). The g\n>> > prefix on the sha1 _fragment_ it to indicate that it is in fact a\n>> > truncated sha1, not a complete one.\n> \n> I think it is there to indicate it is a git commit sha1.\n> \n>>\n>> is this policy documented somewhere? None of the tools understand it.\n>>\n>> [lilydev@haring git]$ git describe\n>> v1.4.3.3-g1e1f76e\n>> [lilydev@haring git]$ git show g1e1f76e\n>> fatal: ambiguous argument 'g1e1f76e': unknown revision or path not in\n>> the working tree.\n>> Use '--' to separate paths from revisions\n>>\n> \n> Use the complete output of describe:\n> $ git show v1.4.3.3-g1e1f76e\n> \n> or the abbrev sha1:\n> $ git show 1e1f76e\n> \n>> My suggestion is to use\n>>\n>> v1.4.3.3+1e1f76e\n> \n> My suggestion is to use:\n> \n> v1.4.3.3-git1e1f76e\n> \n> to make clear that it is a git revision version.\n> \n> One problem I see with this scheme (either 'g', 'git' of '+') is that\n> it does not provide an increasing version number, even for\n> fast-forwarding commits. Then it is not useful as a package version\n> number (deb or rpm). I've already seen deb packages with\n> version+git20061010. One possibility could be to add the number of\n> commits between the tag and the commit as:\n> \n> v1.4.3.3-git12g1e1f76e\n> \n> to provide a weak ordering for fast-forwarding commits. What do you thing?\n\nI think you'll restart the 1.2.3.4 versioning is better 'debate' again!\n\nSurly if things are being pushed into a .deb or .rpm we should be using\na real release version. We should be tagging that. If the project is\nnot providing release number, there is nothing stopping you from tagging\nthem yourself in your copy of the repository and using your tag. you\ncould use like 'unofficial-N' where N increments in the way you want.\n\n"},{"id":"296201","messageId":"4549D519.4080104@xs4all.nl","threadId":"43107","inReplyTo":"8aa486160611020312v42047716t6a13e6fa16eeae8@mail.gmail.com","subject":"Re: Suggestion: drop 'g' in git-describe suffix","fromName":"Han-Wen Nienhuys","fromEmail":"hanwen@xs4all.nl","sentAt":"2006-11-02T11:23:05Z","receivedAt":"2006-11-02T11:23:05Z","isPatch":false,"sender":{"key":"hanwen@google.com","avatar":"https://avatars.githubusercontent.com/u/31547?v=4"},"body":"Santi Béjar escreveu:\n> One problem I see with this scheme (either 'g', 'git' of '+') is that\n> it does not provide an increasing version number, even for\n> fast-forwarding commits. Then it is not useful as a package version\n> number (deb or rpm). I've already seen deb packages with\n> version+git20061010. One possibility could be to add the number of\n> commits between the tag and the commit as:\n> \n> v1.4.3.3-git12g1e1f76e\n> \n> to provide a weak ordering for fast-forwarding commits. What do you thing?\n\nIs that number well defined if you merge branches in between?\n\nI'd prefer\n\n v1.4.3.3+git-12-1e1f76e\n\nor similar. Pasting together words without separator is bad for readability.\n\n-- \n"},{"id":"294109","messageId":"8aa486160611020439r255bcdb1q6e7ece46c77de11c@mail.gmail.com","threadId":"43107","inReplyTo":"4549D4B4.4030601@shadowen.org","subject":"Re: Suggestion: drop 'g' in git-describe suffix","fromName":"Santi Béjar","fromEmail":"sbejar@gmail.com","sentAt":"2006-11-02T12:39:26Z","receivedAt":"2006-11-02T12:39:26Z","isPatch":false,"sender":{"key":"santi@agolina.net","avatar":null},"body":"On 11/2/06, Andy Whitcroft wrote:\n> Santi Béjar wrote:\n> > One problem I see with this scheme (either 'g', 'git' of '+') is that\n> > it does not provide an increasing version number, even for\n> > fast-forwarding commits. Then it is not useful as a package version\n> > number (deb or rpm). I've already seen deb packages with\n> > version+git20061010. One possibility could be to add the number of\n> > commits between the tag and the commit as:\n> >\n> > v1.4.3.3-git12g1e1f76e\n> >\n> > to provide a weak ordering for fast-forwarding commits. What do you thing?\n>\n> I think you'll restart the 1.2.3.4 versioning is better 'debate' again!\n\nSorry, I don't undestand this.\n\n> Surly if things are being pushed into a .deb or .rpm we should be using\n> a real release version. We should be tagging that. If the project is\n> not providing release number, there is nothing stopping you from tagging\n> them yourself in your copy of the repository and using your tag. you\n> could use like 'unofficial-N' where N increments in the way you want.\n\nAnd where do you store this tag? It is an upstream commit and you just\nrefer to this. With the unofficial-N there is no way to know which\nupstream commit you are refering without having access to the git\nrepository of the packager .\n\n"},{"id":"298695","messageId":"8aa486160611020444v130c41f4y3639868cb28e7c38@mail.gmail.com","threadId":"43107","inReplyTo":"4549D519.4080104@xs4all.nl","subject":"Re: Suggestion: drop 'g' in git-describe suffix","fromName":"Santi Béjar","fromEmail":"sbejar@gmail.com","sentAt":"2006-11-02T12:44:05Z","receivedAt":"2006-11-02T12:44:05Z","isPatch":false,"sender":{"key":"santi@agolina.net","avatar":null},"body":"On 11/2/06, Han-Wen Nienhuys wrote:\n> Santi Béjar escreveu:\n> > One problem I see with this scheme (either 'g', 'git' of '+') is that\n> > it does not provide an increasing version number, even for\n> > fast-forwarding commits. Then it is not useful as a package version\n> > number (deb or rpm). I've already seen deb packages with\n> > version+git20061010. One possibility could be to add the number of\n> > commits between the tag and the commit as:\n> >\n> > v1.4.3.3-git12g1e1f76e\n> >\n> > to provide a weak ordering for fast-forwarding commits. What do you thing?\n>\n> Is that number well defined if you merge branches in between?\n\nYes.\n\n$ git-rev-list 1e1f76e ^v1.4.3.3 | wc -l\n\n>\n> I'd prefer\n>\n> v1.4.3.3+git-12-1e1f76e\n>\n> or similar. Pasting together words without separator is bad for readability.\n>\n> --\n> Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen\n"},{"id":"296140","messageId":"8764dyvu74.wl%cworth@cworth.org","threadId":"43107","inReplyTo":"20061102110331.GJ20017@pasky.or.cz","subject":"Re: Suggestion: drop 'g' in git-describe suffix","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2006-11-02T13:45:03Z","receivedAt":"2006-11-02T13:45:03Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Thu, 2 Nov 2006 12:03:31 +0100, Petr Baudis wrote:\n>\n> Dear diary, on Thu, Nov 02, 2006 at 11:37:31AM CET, I got a letter\n> where Andy Whitcroft said that...\n> > The g prefix on the sha1 _fragment_ it to indicate that it is in fact\n> > a truncated sha1, not a complete one.\n>\n> I think it's rather to indicate that it is a sha1 at all.\n\nFrankly, I've never understood the 'g' prefix at all. I don't use\ngit-describe much, but some people have sent me things with this 'g'\non the front and every time I've received that I was annoyed to find\nthe commit identifier they sent didn't work until I manually removed\nit.\n\nIt's definitely never provided any useful semantic information to me.\n\n-Carl\n"},{"id":"295875","messageId":"4549F821.9090600@shadowen.org","threadId":"43107","inReplyTo":"8aa486160611020439r255bcdb1q6e7ece46c77de11c@mail.gmail.com","subject":"Re: Suggestion: drop 'g' in git-describe suffix","fromName":"Andy Whitcroft","fromEmail":"apw@shadowen.org","sentAt":"2006-11-02T13:52:33Z","receivedAt":"2006-11-02T13:52:33Z","isPatch":false,"sender":{"key":"apw@shadowen.org","avatar":"https://gravatar.com/avatar/d3088262854661a913ef35cc40fedcc270142d4461791142bc1ea0b2a4e2e147?d=mp&s=160"},"body":"Santi Béjar wrote:\n> On 11/2/06, Andy Whitcroft wrote:\n>> Santi Béjar wrote:\n>> > One problem I see with this scheme (either 'g', 'git' of '+') is that\n>> > it does not provide an increasing version number, even for\n>> > fast-forwarding commits. Then it is not useful as a package version\n>> > number (deb or rpm). I've already seen deb packages with\n>> > version+git20061010. One possibility could be to add the number of\n>> > commits between the tag and the commit as:\n>> >\n>> > v1.4.3.3-git12g1e1f76e\n>> >\n>> > to provide a weak ordering for fast-forwarding commits. What do you\n>> thing?\n>>\n>> I think you'll restart the 1.2.3.4 versioning is better 'debate' again!\n> \n> Sorry, I don't undestand this.\n\nThere was a long running debate between sha1's and version 'numbers'\n1.2.3.4 for each revision.\n> \n>> Surly if things are being pushed into a .deb or .rpm we should be using\n>> a real release version. We should be tagging that. If the project is\n>> not providing release number, there is nothing stopping you from tagging\n>> them yourself in your copy of the repository and using your tag. you\n>> could use like 'unofficial-N' where N increments in the way you want.\n> \n> And where do you store this tag? It is an upstream commit and you just\n> refer to this. With the unofficial-N there is no way to know which\n> upstream commit you are refering without having access to the git\n> repository of the packager .\n\nYes that is completly true, but its normally the packer who is doing the\nbug fixing of the .deb when its broken. The key problem is you need\nyour numbering to be stable. The only guarenteed stable thing is the\nsha1, tags can change. IMHO you should be including the full sha1 in\nthe --version output and the package descript, whatever versioning you\nare using on the .deb itself.\n\nThat said I guess it would be pretty easy to come up with something to\ncount the number of commits since the last valid tag, something like\nthat below. Might not be pretty, nor so easy to turn back into a commit\nof course.\n\n-apw\n\n#!/bin/sh\n\nlet n=0\ngit log --pretty=one \"$@\" | \\\n awk '{print $1}' | \\\n git name-rev --tags --stdin | \\\n{\n while read sha1 name\n do\n if [ \"$name\" != \"\" ]; then\n echo \"$sha1 $name $n\"\n exit 0\n fi\n let \"n=n+1\"\n done\n echo \"- unknown 0\"\n exit 1\n"},{"id":"293854","messageId":"eicu37$qui$1@sea.gmane.org","threadId":"43107","inReplyTo":"4549D519.4080104@xs4all.nl","subject":"Re: Suggestion: drop 'g' in git-describe suffix","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-11-02T14:07:53Z","receivedAt":"2006-11-02T14:07:53Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Han-Wen Nienhuys wrote:\n\n> Santi Béjar escreveu:\n>> One problem I see with this scheme (either 'g', 'git' of '+') is that\n>> it does not provide an increasing version number, even for\n>> fast-forwarding commits. Then it is not useful as a package version\n>> number (deb or rpm). I've already seen deb packages with\n>> version+git20061010. One possibility could be to add the number of\n>> commits between the tag and the commit as:\n>> \n>> v1.4.3.3-git12g1e1f76e\n>> \n>> to provide a weak ordering for fast-forwarding commits. What do you thing?\n> \n> Is that number well defined if you merge branches in between?\n> \n> I'd prefer\n> \n> v1.4.3.3+git-12-1e1f76e\n> \n> or similar. Pasting together words without separator is bad for readability.\n\nOr even IMVHO better:\n\n v1.4.3.3+12--1e1f76e\n\nor something like that. v1.4.3.3+12 part meaning that v1.4.3.3 is 12 ancestor\nin direct shortest direct line, or that v1.4.3.3+12 is 12 generations away\nfrom v1.4.3.3.\n\nOf course that is _costly_ to confitm that, and v1.4.3.3+12 might mean more\nthan one revision in presence of branching points, especially that there is\nno equivalent of \"first parent\" to distinguish like in case of v1.4.3.3~12\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"294364","messageId":"454A0538.9000104@iaglans.de","threadId":"43107","inReplyTo":"8aa486160611020312v42047716t6a13e6fa16eeae8@mail.gmail.com","subject":"Re: Suggestion: drop 'g' in git-describe suffix","fromName":"Nicolas Vilz 'niv'","fromEmail":"niv@iaglans.de","sentAt":"2006-11-02T14:48:24Z","receivedAt":"2006-11-02T14:48:24Z","isPatch":false,"sender":{"key":"niv@iaglans.de","avatar":"https://gravatar.com/avatar/e4d43a32d721241212d4edb1d2210327e28423c913071b4bfeeaa0ce15296110?d=mp&s=160"},"body":"Santi Béjar wrote:\n> On 11/2/06, Han-Wen Nienhuys wrote:\n>> Andy Whitcroft escreveu:\n>> > Han-Wen Nienhuys wrote:\n>> >>\n>> >> tag+sha1\n>> >>\n>> >> to separate the tag and the committish.\n>> >\n>> > Well there is a non-alphabet character in there, a minus (-). The g\n>> > prefix on the sha1 _fragment_ it to indicate that it is in fact a\n>> > truncated sha1, not a complete one.\n> \n> I think it is there to indicate it is a git commit sha1.\n> \n>>\n>> is this policy documented somewhere? None of the tools understand it.\n>>\n>> [lilydev@haring git]$ git describe\n>> v1.4.3.3-g1e1f76e\n>> [lilydev@haring git]$ git show g1e1f76e\n>> fatal: ambiguous argument 'g1e1f76e': unknown revision or path not in\n>> the working tree.\n>> Use '--' to separate paths from revisions\n>>\n> \n> Use the complete output of describe:\n> $ git show v1.4.3.3-g1e1f76e\n\nthis one doesn't work for me in my repository.\n\n$ git-describe\nrelease_1_22_v0.7-g85eb121\n\n$ git show release_1_22_v0.7-g85eb121\nfatal: ambiguous argument 'release_1_22_v0.7-g85eb121': unknown revision \nor path not in the working tree.\nUse '--' to separate paths from revisions\n\n\n> or the abbrev sha1:\n> $ git show 1e1f76e\nthis one works with my repository\n\n$ git show 85eb121\n\ni use git version 1.4.2.rc2.g2686c\n\n(that was next branch of git one or two days ago or so..)\n\nit would be great to let the full output of git describe work as well.\n\nSincerly\n"},{"id":"294946","messageId":"Pine.LNX.4.63.0611021559430.1670@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"43107","inReplyTo":"454A0538.9000104@iaglans.de","subject":"Re: Suggestion: drop 'g' in git-describe suffix","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-11-02T15:01:12Z","receivedAt":"2006-11-02T15:01:12Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 2 Nov 2006, Nicolas Vilz 'niv' wrote:\n\n> > Use the complete output of describe:\n> > $ git show v1.4.3.3-g1e1f76e\n> \n> this one doesn't work for me in my repository.\n\nYou need at least v1.4.3-rc1^0~69 (v1.4.2.1-g7dd45e1) for this. You \nindicated in your email that your version is older.\n\nCiao,\nDscho\n"},{"id":"298482","messageId":"454A4337.5070703@iaglans.de","threadId":"43107","inReplyTo":"Pine.LNX.4.63.0611021559430.1670@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: Suggestion: drop 'g' in git-describe suffix","fromName":"Nicolas Vilz 'niv'","fromEmail":"niv@iaglans.de","sentAt":"2006-11-02T19:12:55Z","receivedAt":"2006-11-02T19:12:55Z","isPatch":false,"sender":{"key":"niv@iaglans.de","avatar":"https://gravatar.com/avatar/e4d43a32d721241212d4edb1d2210327e28423c913071b4bfeeaa0ce15296110?d=mp&s=160"},"body":"Johannes Schindelin wrote:\n> Hi,\n> \n> On Thu, 2 Nov 2006, Nicolas Vilz 'niv' wrote:\n> \n>>> Use the complete output of describe:\n>>> $ git show v1.4.3.3-g1e1f76e\n>> this one doesn't work for me in my repository.\n> \n> You need at least v1.4.3-rc1^0~69 (v1.4.2.1-g7dd45e1) for this. You \n> indicated in your email that your version is older.\n\nstrange, from time to time i have to delete the whole git repository, \nnot to get stuck on old revisions. Now with a fresh repository i get a \ncurrent revision and with this version, it works.\n\nThx for help\n"}]}