{"thread":{"id":"22747","subject":"[RFC] Is using git describe resilient enough for setting the build version of git?","startedAt":"2010-02-21T00:48:45Z","lastAt":"2010-02-21T08:42:15Z","messageCount":3,"participants":["Steve Diver","Avery Pennarun"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"135204","messageId":"4B8082ED.7020505@think.zenbe.com","threadId":"22747","inReplyTo":null,"subject":"[RFC] Is using git describe resilient enough for setting the build version of git?","fromName":"Steve Diver","fromEmail":"squelch@think.zenbe.com","sentAt":"2010-02-21T00:48:45Z","receivedAt":"2010-02-21T00:48:45Z","isPatch":false,"sender":{"key":"squelch@think.zenbe.com","avatar":null},"body":"Hi,\n\nI recently ran into a problem with the displayed version number for a \nbuild of MSysgit. After much head scratching on my part, and divine \nintervention from Dscho given his intimate knowledge of the codebase, \nwas it resolved.\n\nMy problem was that although I had checked out the tip of devel branch, \nevery time I ran make, my build version was incorrect, although the hash \nsuffix corresponded to the tip of the devel branch.\n\n$ make\nGIT_VERSION = 1.6.4.msysgit.0.2049.g91809\n...\n\nI was expecting to see 1.7.0 as the version which had been merged a few \ndays ago, and simply inspecting the files did not reveal where the \ndiscrepancy originated.\n\nI had been concentrating on GIT-VERSION-GEN to see how the version was \ngenerated, and then comparing between two machines - one with a \nsuccessful build showing correct version and the other not, but both \nshowing 1.7.0 as DEF_VER and apparently identical repositories - \nJohannes then replied to my query with a request to fetch some tags \nwhich had been overlooked. Viewing the two repositories graphically side \nby side immediately revealed that the build with the incorrect version \nlabel did not have recent tags, and it was not the files I should have \nbeen diffing, but comparing the output of \"git describe\". Problem solved \nafter fetching the new tags.\n\nThis has been a most beneficial learning exercise for me, and I am most \ngrateful, and heartened I was on the right track, but I think I also see \na potential problem.\n\nGIT-VERSION-GEN sets a default value DEF_VER according to the version at \nthe time.\n\nThe two most recent being 1.6.6.2 at revision 82221 and 1.7.0 at e923e\n\nHowever, in the absence of a version, the script uses \"git describe\" to \nretrieve the latest tag, and goes on to use this to create the version \nfile along with the hash suffix at the current HEAD. In my case, the \nlatest tag was 1.6.4 but I was building from the latest source at \nrevision 91809.\n\nReading the manual entry for \"git describe\"[1] there is a note saying \nthat the hash suffix does not guarantee disambiguity, and given that a \ntag may be incorrect or missing, there is a chance - albeit with \ndiminishing odds - that the 5 digit hash/tag combination might lead to \nsome obscure problems at some point along the line.\n\nThe chance of this happening really is low, but there is a chance all \nthe same. We cannot foresee all errors, but identifying, and further \nreducing the odds of some must be good. Without doing the math, a guess \nwould be that the probability of a repeat 5 digit abbreviated hash \nsuffix increases the longer a tagged version is in place, so never will \nbe 100% safe. Relying on the build version alone is not a good test \nunder most circumstances, but in my case I could see that the hash was \ncorrect and the displayed version was unexpected. The other way around \nor one of those rare occasions of a repeat would have gone completely \nunnoticed.\n\nI may be wrong, but the only scenario where I see DEF_VER being used by \nGIT-VERSION-GEN, would be when there are no tags for git describe to \nretrieve. ie \"git pull --no-tags\"\n\nIf my understanding is correct, DEF_VER is unique and set at the same \ntime as the tagged version, so wouldn't it be desirable to cross check, \nor include this value instead of relying solely on the tag when present \nduring the generation of GIT-VERSION-FILE at build time?\n\n\nSteve\n\n1. http://www.kernel.org/pub/software/scm/git/docs/git-describe.html\n"},{"id":"135224","messageId":"32541b131002202207s7e9794cdg94d4bc305a0e9213@mail.gmail.com","threadId":"22747","inReplyTo":"4B8082ED.7020505@think.zenbe.com","subject":"Re: [RFC] Is using git describe resilient enough for setting the build version of git?","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2010-02-21T06:07:05Z","receivedAt":"2010-02-21T06:07:05Z","isPatch":false,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On Sat, Feb 20, 2010 at 7:48 PM, Steve Diver <squelch@think.zenbe.com> wrote:\n> Reading the manual entry for \"git describe\"[1] there is a note saying that\n> the hash suffix does not guarantee disambiguity, and given that a tag may be\n> incorrect or missing, there is a chance - albeit with diminishing odds -\n> that the 5 digit hash/tag combination might lead to some obscure problems at\n> some point along the line.\n>\n> The chance of this happening really is low, but there is a chance all the\n> same. We cannot foresee all errors, but identifying, and further reducing\n> the odds of some must be good. Without doing the math, a guess would be that\n> the probability of a repeat 5 digit abbreviated hash suffix increases the\n> longer a tagged version is in place, so never will be 100% safe.\n\nNot really.  Note that the number *before* the hash is the number of\ncommits between your version and the tag.  So the only way to get an\nactual undetectable overlap would be to have two commits that are both\nthe same number of commits on top of the given tag, *and* both start\nwith the same first five digits.  It's just not very likely at all.\nBesides which, using the hash code feature of git-describe is most\nuseful for the short periods between versions, not as a long-term\nthing.  After a new release comes out it's unlikely anyone will care\nif the previous hash prefixes were overlapping.\n\n> I may be wrong, but the only scenario where I see DEF_VER being used by\n> GIT-VERSION-GEN, would be when there are no tags for git describe to\n> retrieve. ie \"git pull --no-tags\"\n>\n> If my understanding is correct, DEF_VER is unique and set at the same time\n> as the tagged version, so wouldn't it be desirable to cross check, or\n> include this value instead of relying solely on the tag when present during\n> the generation of GIT-VERSION-FILE at build time?\n\nIf I recall correctly, the main reason for DEF_VER is when building\ngit from a tarball, in which case 'git describe' wouldn't be able to\ntell you anything useful.\n\nHave fun,\n\nAvery\n"},{"id":"135231","messageId":"4B80F1E7.4030803@think.zenbe.com","threadId":"22747","inReplyTo":"32541b131002202207s7e9794cdg94d4bc305a0e9213@mail.gmail.com","subject":"Re: [RFC] Is using git describe resilient enough for setting the build version of git?","fromName":"Steve Diver","fromEmail":"squelch@think.zenbe.com","sentAt":"2010-02-21T08:42:15Z","receivedAt":"2010-02-21T08:42:15Z","isPatch":false,"sender":{"key":"squelch@think.zenbe.com","avatar":null},"body":"On 21/02/2010 06:07, Avery Pennarun wrote:\n>\n> On Sat, Feb 20, 2010 at 7:48 PM, Steve Diver<squelch@think.zenbe.com>  wrote:\n>> Reading the manual entry for \"git describe\"[1] there is a note saying that\n>> the hash suffix does not guarantee disambiguity, and given that a tag may be\n>> incorrect or missing, there is a chance - albeit with diminishing odds -\n>> that the 5 digit hash/tag combination might lead to some obscure problems at\n>> some point along the line.\n>>\n>> The chance of this happening really is low, but there is a chance all the\n>> same. We cannot foresee all errors, but identifying, and further reducing\n>> the odds of some must be good. Without doing the math, a guess would be that\n>> the probability of a repeat 5 digit abbreviated hash suffix increases the\n>> longer a tagged version is in place, so never will be 100% safe.\n>\n> Not really.  Note that the number *before* the hash is the number of\n> commits between your version and the tag.  So the only way to get an\n> actual undetectable overlap would be to have two commits that are both\n> the same number of commits on top of the given tag, *and* both start\n> with the same first five digits.  It's just not very likely at all.\n> Besides which, using the hash code feature of git-describe is most\n> useful for the short periods between versions, not as a long-term\n> thing.  After a new release comes out it's unlikely anyone will care\n> if the previous hash prefixes were overlapping.\n>\nThanks for pointing that out, and I concede that it is most unlikely. \nTesting for a minor build revision is probably not a good idea anyway. I \nwas thinking along the lines of testing for version integrity.\n\n>> I may be wrong, but the only scenario where I see DEF_VER being used by\n>> GIT-VERSION-GEN, would be when there are no tags for git describe to\n>> retrieve. ie \"git pull --no-tags\"\n>>\n>> If my understanding is correct, DEF_VER is unique and set at the same time\n>> as the tagged version, so wouldn't it be desirable to cross check, or\n>> include this value instead of relying solely on the tag when present during\n>> the generation of GIT-VERSION-FILE at build time?\n>\n> If I recall correctly, the main reason for DEF_VER is when building\n> git from a tarball, in which case 'git describe' wouldn't be able to\n> tell you anything useful.\n>\nI suppose my point is that relying on the tag alone via git describe, \ndoes not guarantee the correct displayed version. The actual minor build \nis less important. This was the only mechanism that allowed me to \nrecognise something was amiss. It is the major version number that \ninterests me.\n\nTake for example a client application that tests for the git version, \navoids problems in older versions, and utilizes features from the latest \nand greatest. This could all happen at run time, and would be fairly \nresilient, except for when the version is incorrectly applied.\n\nIf the client app used the output from my 1.7.0 build which was \nincorrectly labelled, it would not try to use feature x or would fail \nwith a prompt to install a newer version. The situation could be far \nmore serious if the advertised version was 1.7.0 based on a rogue tag, \nand the build was 1.5.0 - extreme and unlikely, but hopefully \nillustrates my point\n\nWhat I am suggesting is that DEF_VER is not only used as fail over where \ngit describe does not yield anything useful, but is also used for \n\"checks and balances\" purposes where git describe generates something \ndifferent from DEF_VER.\n\nSteve\n"}]}