{"thread":{"id":"22284","subject":"git-describe recognize modified files","startedAt":"2010-01-19T09:53:03Z","lastAt":"2010-01-19T13:07:29Z","messageCount":6,"participants":["tzachi perelstein","Johannes Schindelin","Andreas Krey","Jakub Narebski"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"132091","messageId":"829260.92036.qm@web45202.mail.sp1.yahoo.com","threadId":"22284","inReplyTo":null,"subject":"git-describe recognize modified files","fromName":"tzachi perelstein","fromEmail":"tzachi_perelstein@yahoo.com","sentAt":"2010-01-19T09:53:03Z","receivedAt":"2010-01-19T09:53:03Z","isPatch":false,"sender":{"key":"tzachi_perelstein@yahoo.com","avatar":null},"body":"I use git-describe to form a build version automatically. This allows me\nto deliver temporary builds for testing without having to make manual\ntags for them. The only thing that bothers me about this is that from\nthe output of git-describe I cannot tell if there are some modified\nfiles in tree or not. In both cases I will get the same version. \n\nTo solve this issue, in addition to git-describe, my do_version script\nalso run git-status, and if there are \"modified:\" files then it\nconcatenates the string \"+dirty\" to output of git-describe. This way by\nlooking at the version I'm able to know whether a specific version is\nvalid (checkout-able) or not.\n\nIt would be nice to have this option supported in git-describe IMO. I'm willing to implement that and submit a patch for review, but I'd like to hear your opinion first. \n\nTzachi\n\n\n\n \n"},{"id":"132092","messageId":"alpine.DEB.1.00.1001191134130.3164@intel-tinevez-2-302","threadId":"22284","inReplyTo":"829260.92036.qm@web45202.mail.sp1.yahoo.com","subject":"Re: git-describe recognize modified files","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2010-01-19T10:35:41Z","receivedAt":"2010-01-19T10:35:41Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 19 Jan 2010, tzachi perelstein wrote:\n\n> I use git-describe to form a build version automatically. This allows me\n> to deliver temporary builds for testing without having to make manual\n> tags for them. The only thing that bothers me about this is that from\n> the output of git-describe I cannot tell if there are some modified\n> files in tree or not. In both cases I will get the same version. \n> \n> To solve this issue, in addition to git-describe, my do_version script\n> also run git-status, and if there are \"modified:\" files then it\n> concatenates the string \"+dirty\" to output of git-describe.\n\nThe problem is that this does not describe the exact version you used very \nwell. If you are really serious about describing the exact state you \ndescribed, make a tag (committing the changes to a detached HEAD first, if \nyou do not want the changes in a real branch).\n\nCiao,\nDscho\n"},{"id":"132096","messageId":"20100119122122.GA28667@inner.home.ulmdo.de","threadId":"22284","inReplyTo":"alpine.DEB.1.00.1001191134130.3164@intel-tinevez-2-302","subject":"Re: git-describe recognize modified files","fromName":"Andreas Krey","fromEmail":"a.krey@gmx.de","sentAt":"2010-01-19T12:21:22Z","receivedAt":"2010-01-19T12:21:22Z","isPatch":false,"sender":{"key":"a.krey@gmx.de","avatar":"https://avatars.githubusercontent.com/u/37810?v=4"},"body":"On Tue, 19 Jan 2010 11:35:41 +0000, Johannes Schindelin wrote:\n...\n> > To solve this issue, in addition to git-describe, my do_version script\n> > also run git-status, and if there are \"modified:\" files then it\n> > concatenates the string \"+dirty\" to output of git-describe.\n> \n> The problem is that this does not describe the exact version you used very \n> well.\n\nI (and probably the original poster) don't care that much; for me the\nimportant information is that the binary (or whatever) was not built\nfrom the exact committed state. Thus the question is whether the\nsecond two lines of\n\n BUILDINFO=git-`git describe --abbrev=16 --always HEAD 2>/dev/null`\n git update-index -q --refresh\n test -z \"`git diff-index --name-only HEAD --`\" || BUILDINFO=\"$BUILDINFO.dirty\"\n\n(after GIT-VERSION-GEN) are worth to be integrated into git-describe?\n\n(And whether it should also say '.dirty'\n when there are untracked files present.\n Or either for submodules.)\n\nAndreas\n"},{"id":"132098","messageId":"m34omiclap.fsf@localhost.localdomain","threadId":"22284","inReplyTo":"20100119122122.GA28667@inner.home.ulmdo.de","subject":"Re: git-describe recognize modified files","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2010-01-19T12:49:40Z","receivedAt":"2010-01-19T12:49:40Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Andreas Krey writes:\n\n> On Tue, 19 Jan 2010 11:35:41 +0000, Johannes Schindelin wrote:\n> ...\n> > > To solve this issue, in addition to git-describe, my do_version script\n> > > also run git-status, and if there are \"modified:\" files then it\n> > > concatenates the string \"+dirty\" to output of git-describe.\n> > \n> > The problem is that this does not describe the exact version you used very \n> > well.\n> \n> I (and probably the original poster) don't care that much; for me the\n> important information is that the binary (or whatever) was not built\n> from the exact committed state. Thus the question is whether the\n> second two lines of\n> \n> BUILDINFO=git-`git describe --abbrev=16 --always HEAD 2>/dev/null`\n> git update-index -q --refresh\n> test -z \"`git diff-index --name-only HEAD --`\" || BUILDINFO=\"$BUILDINFO.dirty\"\n> \n> (after GIT-VERSION-GEN) are worth to be integrated into git-describe?\n> \n> (And whether it should also say '.dirty'\n> when there are untracked files present.\n> Or either for submodules.)\n\nFYI it is integrated in git-describe since\n\n 9f67d2e (Teach \"git describe\" --dirty option, 2009-10-21)\n\nby Jean Privat (it should be present in 1.6.6, IIRC).\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"132099","messageId":"780857.77695.qm@web45209.mail.sp1.yahoo.com","threadId":"22284","inReplyTo":"alpine.DEB.1.00.1001191134130.3164@intel-tinevez-2-302","subject":"Re: git-describe recognize modified files","fromName":"tzachi perelstein","fromEmail":"tzachi_perelstein@yahoo.com","sentAt":"2010-01-19T12:59:17Z","receivedAt":"2010-01-19T12:59:17Z","isPatch":false,"sender":{"key":"tzachi_perelstein@yahoo.com","avatar":null},"body":"> From: Johannes Schindelin \n> To: tzachi perelstein \n> Cc: git@vger.kernel.org\n> Sent: Tue, January 19, 2010 12:35:41 PM\n> Subject: Re: git-describe recognize modified files\n> \n> Hi,\n> \n> On Tue, 19 Jan 2010, tzachi perelstein wrote:\n> \n> > I use git-describe to form a build version automatically. This allows me\n> > to deliver temporary builds for testing without having to make manual\n> > tags for them. The only thing that bothers me about this is that from\n> > the output of git-describe I cannot tell if there are some modified\n> > files in tree or not. In both cases I will get the same version. \n> > \n> > To solve this issue, in addition to git-describe, my do_version script\n> > also run git-status, and if there are \"modified:\" files then it\n> > concatenates the string \"+dirty\" to output of git-describe.\n> \n> The problem is that this does not describe the exact version you used very \n> well.  If you are really serious about describing the exact state you \n> described, make a tag (committing the changes to a detached HEAD first, if \n> you do not want the changes in a real branch).\n> \n\n\nWell yes, this is valid, but you will end up with a tag for every build... this goes way too far.\n\nConsider the case where you have no modified files in your tree. The output of git-describe at some given point is 'v1.0.0-2-g123457' and during the build it becomes the build version. Now you make some changes, but before committing them you build, install, and run a test. During the second build, the output of git-describe remains the same 'v1.0.0-2-g123457' although it represent two different trees. This behavior looks like somewhat incomplete to me. It sounds reasonable to me to let git-describe have the option of indicating about modified files in tree, say 'v1.0.0-2-g123457-modified' or something similar. While 'v1.0.0-2-g123457' is something you and git can refer to (i.e. checkout), 'v1.0.0-2-g123457-modified' is not. By adding the \"-modified\" string, git tells you explicitly that it cannot fully describe the exact tree you're using.\n\n\n\n \n"},{"id":"132100","messageId":"228075.79497.qm@web45206.mail.sp1.yahoo.com","threadId":"22284","inReplyTo":"m34omiclap.fsf@localhost.localdomain","subject":"Re: git-describe recognize modified files","fromName":"tzachi perelstein","fromEmail":"tzachi_perelstein@yahoo.com","sentAt":"2010-01-19T13:07:29Z","receivedAt":"2010-01-19T13:07:29Z","isPatch":false,"sender":{"key":"tzachi_perelstein@yahoo.com","avatar":null},"body":"> FYI it is integrated in git-describe since\n> \n>   9f67d2e (Teach \"git describe\" --dirty option, 2009-10-21)\n> \n> by Jean Privat (it should be present in 1.6.6, IIRC).\n> \n\nGood news :)\nThanks\n\n\n\n \n"}]}