{"thread":{"id":"33042","subject":"Adding \"--ignore-submodules\" switch to git-describe","startedAt":"2013-03-01T10:16:09Z","lastAt":"2013-03-08T21:26:53Z","messageCount":5,"participants":["Francis Moreau","Junio C Hamano","Jens Lehmann"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"210452","messageId":"CAC9WiBjHEoX154Y2q1NxEB1my78Gqf__+v-KR5jNVqT-MN9ZaQ@mail.gmail.com","threadId":"33042","inReplyTo":null,"subject":"Adding \"--ignore-submodules\" switch to git-describe","fromName":"Francis Moreau","fromEmail":"francis.moro@gmail.com","sentAt":"2013-03-01T10:16:09Z","receivedAt":"2013-03-01T10:16:09Z","isPatch":false,"sender":{"key":"francis.moro@gmail.com","avatar":null},"body":"Hello,\n\nWould it make sense to add the option --ignore-submodules (currently\navailable in git-status) to git-describe when the later is used with\n--dirty option ?\n\nThanks\n-- \nFrancis\n"},{"id":"210467","messageId":"7v621bggi5.fsf@alter.siamese.dyndns.org","threadId":"33042","inReplyTo":"CAC9WiBjHEoX154Y2q1NxEB1my78Gqf__+v-KR5jNVqT-MN9ZaQ@mail.gmail.com","subject":"Re: Adding \"--ignore-submodules\" switch to git-describe","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-03-01T17:46:26Z","receivedAt":"2013-03-01T17:46:26Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Francis Moreau <francis.moro@gmail.com> writes:\n\n> Would it make sense to add the option --ignore-submodules (currently\n> available in git-status) to git-describe when the later is used with\n> --dirty option ?\n\nI think the spirit of \"describe --dirty\" is to allow people who\ngives out binaries this assurance:\n\n\tThe version string I got out of \"describe --dirty\" does not\n\tsay dirty. If the recipient of the binary later reports\n\tissues, I should be able to reproduce the same binary by\n\tstarting from a pristine checkout of the version (provided\n\tif I didn't screw up and depended on an untracked file when\n\tI initially created the binary, or used a custom build\n\toption, or lost the toolchain, ..., of course).\n\nWith that in mind, does --ignore-submodules make sense?\n\nAs we do not take untracked content at the superproject level into\naccount when deciding \"--dirty\"-ness, I think it is very sensible to\neither do one of the following:\n\n (1) always ignore untracked files in submodule working trees; or\n\n (2) if we were to introduce some form of --ignore-submodules,\n     ignore untracked files in the superproject working tree when we\n     use that mechanism to ignore untracked files in submodule\n     working trees.\n\nStrictly speaking, (1) is a degenerate case of (2).\n\nUsing the same semantics of \"--ignore-submodules\" as \"git status\"\nwould not make much sense. \"git status --ignore-submodules\" does not\nshow modified submodules at all (e.g. the gitlink recorded in the\nHEAD of the superproject being described does not match what is\nchecked out), so a clean output from the \"describe --dirty\" at the\nsuperproject level does not give any assurance on the build\nartifact.  It defeats the whole point of \"describe --dirty\".\n\nI think what is missing from \"--dirty\" is not \"--ignore-submodules\",\nbut \"--do-not-ignore-untracked\" option [*1*].  \"describe --dirty\"\nignores untracked files in the superproject by default, and we\nshould ignore untracked files in submodule working trees, but the\ncurrent code does not.  Fixing that is (1) above.\n\nAnd then when \"--do-not-ignore-untracked\" is in effect, we should\nreport a \"dirty\" revision when the working tree of the superproject\nor any of the submodule working trees has untracked cruft.\n\nYou might want to argue, in the longer term, that the default should\nbe \"--do-not-ignore-untracked\" and people who want the current\ntoplevel behaviour should ask it with \"--ignore-untracked\".  I am\nsomewhat sympathetic to that position, but I do not think it is\npractical.  People are not perfect and they do keep untracked and\nunignored paths in the working tree; ignoring untracked paths does\nhave an excuse to be the default from practical point of view.\n\nBut when we ignore untracked paths in the superproject, we should\nignore untracked paths in submodule working trees consistently.\n\n\n[Footnote]\n\n*1* Ignoring any other kind of change in submodules (i.e. \"none\",\n\"dirty\" or \"all\" for \"git status --ignore-submodules=<when>\") in the\ncontext of \"describe --dirty\" in the superproject tree does not make\nany sense, so\n\n\tBAD$ git describe --dirty --ignore-submodules=<when>\n\nis not a right thing to do.\n"},{"id":"210471","messageId":"5131043B.8000701@web.de","threadId":"33042","inReplyTo":"7v621bggi5.fsf@alter.siamese.dyndns.org","subject":"Re: Adding \"--ignore-submodules\" switch to git-describe","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2013-03-01T19:40:43Z","receivedAt":"2013-03-01T19:40:43Z","isPatch":false,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 01.03.2013 18:46, schrieb Junio C Hamano:\n> I think what is missing from \"--dirty\" is not \"--ignore-submodules\",\n> but \"--do-not-ignore-untracked\" option [*1*].  \"describe --dirty\"\n> ignores untracked files in the superproject by default, and we\n> should ignore untracked files in submodule working trees, but the\n> current code does not.  Fixing that is (1) above.\n>\n> And then when \"--do-not-ignore-untracked\" is in effect, we should\n> report a \"dirty\" revision when the working tree of the superproject\n> or any of the submodule working trees has untracked cruft.\n\nI agree with your analysis. What about teaching describe the\n\"-u|--untracked-files\" option which status already knows? The\ntwo modes could be \"no\" and \"yes\" here (as the distinction\nbetween \"normal\" and \"all\" doesn't make any sense for describe).\nCurrent default would be \"no\", using \"-u\" alone would set mode to\n\"yes\".\n\n> You might want to argue, in the longer term, that the default should\n> be \"--do-not-ignore-untracked\" and people who want the current\n> toplevel behaviour should ask it with \"--ignore-untracked\".  I am\n> somewhat sympathetic to that position, but I do not think it is\n> practical.  People are not perfect and they do keep untracked and\n> unignored paths in the working tree; ignoring untracked paths does\n> have an excuse to be the default from practical point of view.\n\nI think the default mostly depends on the habits of the people\nusing a repo. Personally I would lean towards making \"-uyes\" the\ndefault, because in my experience untracked files can make a huge\ndifference when you later try to reproduce a certain version and\nits behavior (and additionally that is just what status already\nuses as default). But I won't care that much about the default if\nwe would just reuse the \"status.showUntrackedFiles\" config option\nto set the default for describe too. This should allow to set the\npolicy per repo or globally to peoples taste. Does that make sense?\n\n> But when we ignore untracked paths in the superproject, we should\n> ignore untracked paths in submodule working trees consistently.\n\nDefinitely (we fixed that for status some time ago in 3bfc45047).\n"},{"id":"210850","messageId":"CAC9WiBhHmqn7QZMLFcLjqGPamHmbMFNxvQ6Yzv5dr=+fe+F3_g@mail.gmail.com","threadId":"33042","inReplyTo":"7v621bggi5.fsf@alter.siamese.dyndns.org","subject":"Re: Adding \"--ignore-submodules\" switch to git-describe","fromName":"Francis Moreau","fromEmail":"francis.moro@gmail.com","sentAt":"2013-03-08T20:04:30Z","receivedAt":"2013-03-08T20:04:30Z","isPatch":false,"sender":{"key":"francis.moro@gmail.com","avatar":null},"body":"Hi,\n\nSorry for the long delay, I somehow missed your answer...\n\nOn Fri, Mar 1, 2013 at 6:46 PM, Junio C Hamano <gitster@pobox.com> wrote:\n> Francis Moreau <francis.moro@gmail.com> writes:\n>\n>> Would it make sense to add the option --ignore-submodules (currently\n>> available in git-status) to git-describe when the later is used with\n>> --dirty option ?\n>\n> I think the spirit of \"describe --dirty\" is to allow people who\n> gives out binaries this assurance:\n>\n>         The version string I got out of \"describe --dirty\" does not\n>         say dirty. If the recipient of the binary later reports\n>         issues, I should be able to reproduce the same binary by\n>         starting from a pristine checkout of the version (provided\n>         if I didn't screw up and depended on an untracked file when\n>         I initially created the binary, or used a custom build\n>         option, or lost the toolchain, ..., of course).\n>\n> With that in mind, does --ignore-submodules make sense?\n\nWell, I wouldn't have thought about this definition of \"describe\n--dirty\". I would have thought that, by default, this command look\nonly at the files that git knows/tracks. There're too many external\n(to the git repo) parameters that could influence the build of a\nproject: environment variables, components of the toolchain, version\nof each components etc... that git doesn't know about.\n\n[...]\n\n>\n> But when we ignore untracked paths in the superproject, we should\n> ignore untracked paths in submodule working trees consistently.\n>\n>\n\nyes I agree.\n\nBut in the short term, could you suggest a method to workaround this\ninconsistency ?\n\nThanks.\n-- \nFrancis\n"},{"id":"210851","messageId":"7vy5dxfuqq.fsf@alter.siamese.dyndns.org","threadId":"33042","inReplyTo":"CAC9WiBhHmqn7QZMLFcLjqGPamHmbMFNxvQ6Yzv5dr=+fe+F3_g@mail.gmail.com","subject":"Re: Adding \"--ignore-submodules\" switch to git-describe","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-03-08T21:26:53Z","receivedAt":"2013-03-08T21:26:53Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Francis Moreau <francis.moro@gmail.com> writes:\n\n>> But when we ignore untracked paths in the superproject, we should\n>> ignore untracked paths in submodule working trees consistently.\n>\n> yes I agree.\n>\n> But in the short term, could you suggest a method to workaround this\n> inconsistency ?\n\nHrm, ... didn't I already?\n\n    As we do not take untracked content at the superproject level into\n    account when deciding \"--dirty\"-ness, I think it is very sensible to\n    either do one of the following:\n\n     (1) always ignore untracked files in submodule working trees; or\n\n     (2) if we were to introduce some form of --ignore-submodules,\n         ignore untracked files in the superproject working tree when we\n         use that mechanism to ignore untracked files in submodule\n         working trees.\n\n    Strictly speaking, (1) is a degenerate case of (2).\n\n    ...\n    I think what is missing from \"--dirty\" is not \"--ignore-submodules\",\n    but \"--do-not-ignore-untracked\" option [*1*].  \"describe --dirty\"\n    ignores untracked files in the superproject by default, and we\n    should ignore untracked files in submodule working trees, but the\n    current code does not.  Fixing that is (1) above.\n\nI think the right first step without any new option is to make\n\"describe --dirty\" to ignore the dirtiness in submodules coming\nsolely from having untracked files in submodules' working trees.\n\nYou could later add --having-untracked-is-dirty option to mark the\noutput dirty when there is an untracked file in submodules' working\ntrees or the toplevel working tree, which would be the second step.\n"}]}