{"thread":{"id":"22268","subject":"Unmodified submodules shows up as dirty with 1.6.6.443.gd7346","startedAt":"2010-01-18T15:30:46Z","lastAt":"2010-01-19T17:29:38Z","messageCount":11,"participants":["Gustaf Hendeby","Jacob Helwig","Junio C Hamano","Jens Lehmann","Johannes Sixt"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"132033","messageId":"4B547EA6.5070203@isy.liu.se","threadId":"22268","inReplyTo":null,"subject":"Unmodified submodules shows up as dirty with 1.6.6.443.gd7346","fromName":"Gustaf Hendeby","fromEmail":"hendeby@isy.liu.se","sentAt":"2010-01-18T15:30:46Z","receivedAt":"2010-01-18T15:30:46Z","isPatch":false,"sender":{"key":"hendeby@isy.liu.se","avatar":"https://avatars.githubusercontent.com/u/730316?v=4"},"body":"Hi!\n\nI have been using submodules for a while, and been quite happy with\nthem.  Just updating to the latest next (1.6.6.443.gd7346), a strange\nproblem has occurred.  All my submodules (which are in fact unmodified)\nshow as modified and dirty\n\ndiff --git a/extern/utils b/extern/utils\n--- a/extern/utils\n+++ b/extern/utils\n@@ -1 +1 @@\n-Subproject commit 6bad20e1419f1ca61bd5a6eef9b5937122e006f1\n+Subproject commit 6bad20e1419f1ca61bd5a6eef9b5937122e006f1-dirty\n\n\nAnyone have an idea what is going on here?  (Related to the recent topic\nby Jens Lehmann? cc:ed)  Unfortunately, I don't have the time to dig\ninto this right now, but I'll try to do it later tonight if the problem\nremains.\n\n/Gustaf\n"},{"id":"132034","messageId":"8c9a061001180802t5ec0d389j2cae9f1771130c36@mail.gmail.com","threadId":"22268","inReplyTo":"4B547EA6.5070203@isy.liu.se","subject":"Re: Unmodified submodules shows up as dirty with 1.6.6.443.gd7346","fromName":"Jacob Helwig","fromEmail":"jacob.helwig@gmail.com","sentAt":"2010-01-18T16:02:26Z","receivedAt":"2010-01-18T16:02:26Z","isPatch":false,"sender":{"key":"jacob.helwig@gmail.com","avatar":"https://avatars.githubusercontent.com/u/14557?v=4"},"body":"On Mon, Jan 18, 2010 at 07:30, Gustaf Hendeby <hendeby@isy.liu.se> wrote:\n> Hi!\n>\n> I have been using submodules for a while, and been quite happy with\n> them.  Just updating to the latest next (1.6.6.443.gd7346), a strange\n> problem has occurred.  All my submodules (which are in fact unmodified)\n> show as modified and dirty\n>\n> diff --git a/extern/utils b/extern/utils\n> --- a/extern/utils\n> +++ b/extern/utils\n> @@ -1 +1 @@\n> -Subproject commit 6bad20e1419f1ca61bd5a6eef9b5937122e006f1\n> +Subproject commit 6bad20e1419f1ca61bd5a6eef9b5937122e006f1-dirty\n>\n>\n> Anyone have an idea what is going on here?  (Related to the recent topic\n> by Jens Lehmann? cc:ed)  Unfortunately, I don't have the time to dig\n> into this right now, but I'll try to do it later tonight if the problem\n> remains.\n>\n> /Gustaf\n>\n\nDo you have any untracked files in the submodule?  git status is\nworking as I would expect with the same version (1.6.6.443.gd7346).\n\nIf there is no output from git status in the submodule, then git\nstatus in the superproject shows the submodule as being clean.\nHowever, if there is _any_ output from git status (untracked files,\nmodified files, deleted files, new files), then the superproject shows\nthe submodule as being dirty.\n\n-Jacob\n"},{"id":"132035","messageId":"4B549254.5090206@isy.liu.se","threadId":"22268","inReplyTo":"8c9a061001180802t5ec0d389j2cae9f1771130c36@mail.gmail.com","subject":"Re: Unmodified submodules shows up as dirty with 1.6.6.443.gd7346","fromName":"Gustaf Hendeby","fromEmail":"hendeby@isy.liu.se","sentAt":"2010-01-18T16:54:44Z","receivedAt":"2010-01-18T16:54:44Z","isPatch":false,"sender":{"key":"hendeby@isy.liu.se","avatar":"https://avatars.githubusercontent.com/u/730316?v=4"},"body":"Jacob Helwig wrote:\n> On Mon, Jan 18, 2010 at 07:30, Gustaf Hendeby <hendeby@isy.liu.se> wrote:\n>> Hi!\n>>\n>> I have been using submodules for a while, and been quite happy with\n>> them.  Just updating to the latest next (1.6.6.443.gd7346), a strange\n>> problem has occurred.  All my submodules (which are in fact unmodified)\n>> show as modified and dirty\n>>\n>> diff --git a/extern/utils b/extern/utils\n>> --- a/extern/utils\n>> +++ b/extern/utils\n>> @@ -1 +1 @@\n>> -Subproject commit 6bad20e1419f1ca61bd5a6eef9b5937122e006f1\n>> +Subproject commit 6bad20e1419f1ca61bd5a6eef9b5937122e006f1-dirty\n>>\n>>\n> Do you have any untracked files in the submodule?  git status is\n> working as I would expect with the same version (1.6.6.443.gd7346).\n\nYes, I do.\n\n> \n> If there is no output from git status in the submodule, then git\n> status in the superproject shows the submodule as being clean.\n> However, if there is _any_ output from git status (untracked files,\n> modified files, deleted files, new files), then the superproject shows\n> the submodule as being dirty.\n> \n\nThen the behavior of this feature differs from the one provided by\nGIT-VERSION-GEN that is used as part of the git build process.  This is\nnot an argument itself, but personally, I don't like this behavior, and\nthink it should be reconsidered before inclusion into master.\n\nI have the following use case, which is affected.  I have with in a\nsubmodule some code that needs to be compiled, and hence generate some\nobject files and other files in the process.  I don't want to include\nthese files in a .gitignore as they are named differently on different\nsystems.  Hence, I include them in my .git/info/exclude file, where I am\ndeveloping the module.  So now, unless I do the same thing for all\nplaces I checkout the repo as submodule, I end up with the module\nindicated as dirty after I compile it.  This is a bit inconvenient.\n\nAm I the only one who uses submodules this way?  Is there a better way\nto solve my problem that would provide a better work pattern in this case?\n\n/Gustaf\n"},{"id":"132037","messageId":"8c9a061001180914v42074056o3a5d077ac4cea70f@mail.gmail.com","threadId":"22268","inReplyTo":"4B549254.5090206@isy.liu.se","subject":"Re: Unmodified submodules shows up as dirty with 1.6.6.443.gd7346","fromName":"Jacob Helwig","fromEmail":"jacob.helwig@gmail.com","sentAt":"2010-01-18T17:14:55Z","receivedAt":"2010-01-18T17:14:55Z","isPatch":false,"sender":{"key":"jacob.helwig@gmail.com","avatar":"https://avatars.githubusercontent.com/u/14557?v=4"},"body":"On Mon, Jan 18, 2010 at 08:54, Gustaf Hendeby <hendeby@isy.liu.se> wrote:\n> Jacob Helwig wrote:\n>> On Mon, Jan 18, 2010 at 07:30, Gustaf Hendeby <hendeby@isy.liu.se> wrote:\n>>> Hi!\n>>>\n>>> I have been using submodules for a while, and been quite happy with\n>>> them.  Just updating to the latest next (1.6.6.443.gd7346), a strange\n>>> problem has occurred.  All my submodules (which are in fact unmodified)\n>>> show as modified and dirty\n>>>\n>>> diff --git a/extern/utils b/extern/utils\n>>> --- a/extern/utils\n>>> +++ b/extern/utils\n>>> @@ -1 +1 @@\n>>> -Subproject commit 6bad20e1419f1ca61bd5a6eef9b5937122e006f1\n>>> +Subproject commit 6bad20e1419f1ca61bd5a6eef9b5937122e006f1-dirty\n>>>\n>>>\n>> Do you have any untracked files in the submodule?  git status is\n>> working as I would expect with the same version (1.6.6.443.gd7346).\n>\n> Yes, I do.\n>\n>>\n>> If there is no output from git status in the submodule, then git\n>> status in the superproject shows the submodule as being clean.\n>> However, if there is _any_ output from git status (untracked files,\n>> modified files, deleted files, new files), then the superproject shows\n>> the submodule as being dirty.\n>>\n>\n> Then the behavior of this feature differs from the one provided by\n> GIT-VERSION-GEN that is used as part of the git build process.  This is\n> not an argument itself, but personally, I don't like this behavior, and\n> think it should be reconsidered before inclusion into master.\n>\n> I have the following use case, which is affected.  I have with in a\n> submodule some code that needs to be compiled, and hence generate some\n> object files and other files in the process.  I don't want to include\n> these files in a .gitignore as they are named differently on different\n> systems.  Hence, I include them in my .git/info/exclude file, where I am\n> developing the module.  So now, unless I do the same thing for all\n> places I checkout the repo as submodule, I end up with the module\n> indicated as dirty after I compile it.  This is a bit inconvenient.\n>\n> Am I the only one who uses submodules this way?  Is there a better way\n> to solve my problem that would provide a better work pattern in this case?\n>\n> /Gustaf\n>\n\nI don't really deal with compiled code, when I use submodules, so any\ntime there's a new file in one of my submodules, it's almost certainly\na new library file that should make the submodule be considered\n\"dirty\".  Even though the current behavior is what I'd expect, and\nwant for my uses, that doesn't mean it's not wrong for some other use\ncases.\n\nThat being said:\nThe .gitignore file supports shell globs.  Are the generated files\ncreated with names that are so different that some simple shell globs\nused in one or more .gitignore files couldn't cover them?\n\n-Jacob\n"},{"id":"132038","messageId":"7vr5pnqqem.fsf@alter.siamese.dyndns.org","threadId":"22268","inReplyTo":"4B549254.5090206@isy.liu.se","subject":"Re: Unmodified submodules shows up as dirty with 1.6.6.443.gd7346","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-01-18T17:22:25Z","receivedAt":"2010-01-18T17:22:25Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Gustaf Hendeby <hendeby@isy.liu.se> writes:\n\n> ....  I don't want to include\n> these files in a .gitignore as they are named differently on different\n> systems.  Hence, I include them in my .git/info/exclude file,...\n\nI don't have a strong opinion on the submodules part of your issue, but\nthe above part applies to projects with or without submodules, which I\nhave an opinion, and because it is different from what I used to teach\npeople, I think it is worth mentioning..\n\nI used to say \"Never place *~ (or *.swp) in .gitignore because they are\nonly useful to you who use Emacs (or vim); and do have *.o in .gitignore,\nbecause everybody who compile your checkout would see it\".\n\nBut I don't think the former is a right attitude.  My thinking these days\nis that keeping these in .gitignore should not just be tolerated but\nshould be actively encouraged, unless the project may need to track paths\nthat match *~ or *.swp in the future,\n\nIf it is very unlikely that the project will ever track them, there is no\nharm done [*1*], and it will help other people because they don't have to\nadd the same and common entries in their own .git/info/excludes file.\n\nI am suspecting that your \"these files ... are named differently on\ndifferent systems\" may fall into the same category.  Your build may not\nproduce \"frotz.linux\" when compiled on a FreeBSD box (and \"frotz.fbsd\" on\na Linux box), but would it hurt more than it helps to list them in the\nsame .gitignore to cover both?\n\n\n[Footnote]\n\n*1* Once it starts doing so, un-ignoring a special case can be done\nat that point in the history\n"},{"id":"132039","messageId":"4B549A1B.9060306@isy.liu.se","threadId":"22268","inReplyTo":"8c9a061001180914v42074056o3a5d077ac4cea70f@mail.gmail.com","subject":"Re: Unmodified submodules shows up as dirty with 1.6.6.443.gd7346","fromName":"Gustaf Hendeby","fromEmail":"hendeby@isy.liu.se","sentAt":"2010-01-18T17:27:55Z","receivedAt":"2010-01-18T17:27:55Z","isPatch":false,"sender":{"key":"hendeby@isy.liu.se","avatar":"https://avatars.githubusercontent.com/u/730316?v=4"},"body":"Jacob Helwig wrote:\n> On Mon, Jan 18, 2010 at 08:54, Gustaf Hendeby <hendeby@isy.liu.se> wrote:\n>> Jacob Helwig wrote:\n>>> On Mon, Jan 18, 2010 at 07:30, Gustaf Hendeby <hendeby@isy.liu.se> wrote:\n>>>> Hi!\n>>>>\n>>>> I have been using submodules for a while, and been quite happy with\n>>>> them.  Just updating to the latest next (1.6.6.443.gd7346), a strange\n>>>> problem has occurred.  All my submodules (which are in fact unmodified)\n>>>> show as modified and dirty\n>>>>\n>>>> diff --git a/extern/utils b/extern/utils\n>>>> --- a/extern/utils\n>>>> +++ b/extern/utils\n>>>> @@ -1 +1 @@\n>>>> -Subproject commit 6bad20e1419f1ca61bd5a6eef9b5937122e006f1\n>>>> +Subproject commit 6bad20e1419f1ca61bd5a6eef9b5937122e006f1-dirty\n>>>>\n>>>>\n>>> Do you have any untracked files in the submodule?  git status is\n>>> working as I would expect with the same version (1.6.6.443.gd7346).\n>> Yes, I do.\n>>\n>>> If there is no output from git status in the submodule, then git\n>>> status in the superproject shows the submodule as being clean.\n>>> However, if there is _any_ output from git status (untracked files,\n>>> modified files, deleted files, new files), then the superproject shows\n>>> the submodule as being dirty.\n>>>\n>> I have the following use case, which is affected.  I have with in a\n>> submodule some code that needs to be compiled, and hence generate some\n>> object files and other files in the process.  I don't want to include\n>> these files in a .gitignore as they are named differently on different\n>> systems.  Hence, I include them in my .git/info/exclude file, where I am\n>> developing the module.  So now, unless I do the same thing for all\n>> places I checkout the repo as submodule, I end up with the module\n>> indicated as dirty after I compile it.  This is a bit inconvenient.\n> \n> That being said:\n> The .gitignore file supports shell globs.  Are the generated files\n> created with names that are so different that some simple shell globs\n> used in one or more .gitignore files couldn't cover them?\n\nUnder Linux I for example get .o files whereas under Windows I get .obj\nfiles.  Of course I could put both in .gitignore, but I don't like to\nhave to exclude more files than necessary it gives me a bad feeling of\naccidentally one day exclude something important, which has at occasions\nhappened before.  (For the same reason i don't usually put *~ in\n.gitignore, as I don't want to impose emacs on others, that might prefer\na different editor, but that is a bit different from the case we have\nhere.)  Furthermore, list could start to grow with more systems and\nbuild chains with more intermediate files.\n\n/Gustaf\n"},{"id":"132050","messageId":"4B54C97B.1050008@web.de","threadId":"22268","inReplyTo":"7vr5pnqqem.fsf@alter.siamese.dyndns.org","subject":"Re: Unmodified submodules shows up as dirty with 1.6.6.443.gd7346","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2010-01-18T20:50:03Z","receivedAt":"2010-01-18T20:50:03Z","isPatch":false,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 18.01.2010 18:22, schrieb Junio C Hamano:\n> I am suspecting that your \"these files ... are named differently on\n> different systems\" may fall into the same category.  Your build may not\n> produce \"frotz.linux\" when compiled on a FreeBSD box (and \"frotz.fbsd\" on\n> a Linux box), but would it hurt more than it helps to list them in the\n> same .gitignore to cover both?\n\nIf you keep source directories separate from directories for compiler\noutput you can easily simplify your .gitignore by negating it. So\ninstead of putting a line into the .gitignore for every file type you\ndo /not/ want, exclude everything in the build directory and add\nexceptions for the files you /do/ want to track.\n\nThen a .gitignore could look like this for building with VC6, VC8 and\nMakefile based build systems:\n\npath/to/build/directory/*\n!*.dsw\n!*.dsp\n!*.sln\n!*.vcproj\n!Makefile\n"},{"id":"132082","messageId":"4B555BA1.90605@viscovery.net","threadId":"22268","inReplyTo":"8c9a061001180802t5ec0d389j2cae9f1771130c36@mail.gmail.com","subject":"Re: Unmodified submodules shows up as dirty with 1.6.6.443.gd7346","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2010-01-19T07:13:37Z","receivedAt":"2010-01-19T07:13:37Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Jacob Helwig schrieb:\n> If there is no output from git status in the submodule, then git\n> status in the superproject shows the submodule as being clean.\n> However, if there is _any_ output from git status (untracked files,\n> modified files, deleted files, new files), then the superproject shows\n> the submodule as being dirty.\n\nBut isn't it a bug that a submodule is considered dirty just because an\nuntracked file appears?\n\n-- Hannes\n"},{"id":"132087","messageId":"4B556C0A.9020204@isy.liu.se","threadId":"22268","inReplyTo":"4B555BA1.90605@viscovery.net","subject":"Re: Unmodified submodules shows up as dirty with 1.6.6.443.gd7346","fromName":"Gustaf Hendeby","fromEmail":"hendeby@isy.liu.se","sentAt":"2010-01-19T08:23:38Z","receivedAt":"2010-01-19T08:23:38Z","isPatch":false,"sender":{"key":"hendeby@isy.liu.se","avatar":"https://avatars.githubusercontent.com/u/730316?v=4"},"body":"Johannes Sixt wrote:\n> Jacob Helwig schrieb:\n>> If there is no output from git status in the submodule, then git\n>> status in the superproject shows the submodule as being clean.\n>> However, if there is _any_ output from git status (untracked files,\n>> modified files, deleted files, new files), then the superproject shows\n>> the submodule as being dirty.\n> \n> But isn't it a bug that a submodule is considered dirty just because an\n> untracked file appears?\n\nI prefer the old behavior, and find the new one a bit unintuitive and I\nsuspect it will hit more people than just me once the change ends up on\nmaster.  Unfortunately, the response yesterday pointed in the direction\nof this being a wanted feature.  I think the change of behavior should\nat least be mentioned in the release note.\n\n/Gustaf\n"},{"id":"132105","messageId":"8c9a061001190631rb1f9518sff337e07e0a6803@mail.gmail.com","threadId":"22268","inReplyTo":"4B555BA1.90605@viscovery.net","subject":"Re: Unmodified submodules shows up as dirty with 1.6.6.443.gd7346","fromName":"Jacob Helwig","fromEmail":"jacob.helwig@gmail.com","sentAt":"2010-01-19T14:31:51Z","receivedAt":"2010-01-19T14:31:51Z","isPatch":false,"sender":{"key":"jacob.helwig@gmail.com","avatar":"https://avatars.githubusercontent.com/u/14557?v=4"},"body":"On Mon, Jan 18, 2010 at 23:13, Johannes Sixt <j.sixt@viscovery.net> wrote:\n> Jacob Helwig schrieb:\n>> If there is no output from git status in the submodule, then git\n>> status in the superproject shows the submodule as being clean.\n>> However, if there is _any_ output from git status (untracked files,\n>> modified files, deleted files, new files), then the superproject shows\n>> the submodule as being dirty.\n>\n> But isn't it a bug that a submodule is considered dirty just because an\n> untracked file appears?\n>\n> -- Hannes\n>\n\nI wouldn't consider it a bug, but that's specific to my use case of submodules.\n\nAt work, we're using them for shared Perl libraries between projects.\nThe only reason we have for creating new, untracked files in the\nsubmodule is that we're adding new library code.  Having the submodule\nshow up as dirty for us is another safety towards not forgetting to\ncommit & push out this new code.\n\nI agree that this isn't intuitive given how status normally handles\nfiles in projects, but it makes sense (to me, anyway), when dealing\nwith library code.\n\nShould this be the default behavior for everyone?  I can't say.  If\nit's not, I would at least like it to be behavior that you can opt-in\nto.\n\n-Jacob\n"},{"id":"132121","messageId":"7v1vhmatq5.fsf@alter.siamese.dyndns.org","threadId":"22268","inReplyTo":"4B555BA1.90605@viscovery.net","subject":"Re: Unmodified submodules shows up as dirty with 1.6.6.443.gd7346","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-01-19T17:29:38Z","receivedAt":"2010-01-19T17:29:38Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Sixt <j.sixt@viscovery.net> writes:\n\n> Jacob Helwig schrieb:\n>> If there is no output from git status in the submodule, then git\n>> status in the superproject shows the submodule as being clean.\n>> However, if there is _any_ output from git status (untracked files,\n>> modified files, deleted files, new files), then the superproject shows\n>> the submodule as being dirty.\n>\n> But isn't it a bug that a submodule is considered dirty just because an\n> untracked file appears?\n\nMy take while commenting on this series has been that we have been buggy\nnot to show submodule dirty when the end user may have files he forgot to\nadd, just like \"git status\" reminds them at the end.\n"}]}