Re: Unmodified submodules shows up as dirty with 1.6.6.443.gd7346

From: Gustaf Hendeby <hendeby@isy.liu.se>
Date: Jan 18, 2010, 17:27 UTC
Message-ID: <4B549A1B.9060306@isy.liu.se>
In-Reply-To: <8c9a061001180914v42074056o3a5d077ac4cea70f@mail.gmail.com>

Jacob Helwig wrote:

Show 41 quoted lines

> On Mon, Jan 18, 2010 at 08:54, Gustaf Hendeby <hendeby@isy.liu.se> wrote:
>> Jacob Helwig wrote:
>>> On Mon, Jan 18, 2010 at 07:30, Gustaf Hendeby <hendeby@isy.liu.se> wrote:
>>>> Hi!
>>>>
>>>> I have been using submodules for a while, and been quite happy with
>>>> them.  Just updating to the latest next (1.6.6.443.gd7346), a strange
>>>> problem has occurred.  All my submodules (which are in fact unmodified)
>>>> show as modified and dirty
>>>>
>>>> diff --git a/extern/utils b/extern/utils
>>>> --- a/extern/utils
>>>> +++ b/extern/utils
>>>> @@ -1 +1 @@
>>>> -Subproject commit 6bad20e1419f1ca61bd5a6eef9b5937122e006f1
>>>> +Subproject commit 6bad20e1419f1ca61bd5a6eef9b5937122e006f1-dirty
>>>>
>>>>
>>> Do you have any untracked files in the submodule?  git status is
>>> working as I would expect with the same version (1.6.6.443.gd7346).
>> Yes, I do.
>>
>>> If there is no output from git status in the submodule, then git
>>> status in the superproject shows the submodule as being clean.
>>> However, if there is _any_ output from git status (untracked files,
>>> modified files, deleted files, new files), then the superproject shows
>>> the submodule as being dirty.
>>>
>> I have the following use case, which is affected.  I have with in a
>> submodule some code that needs to be compiled, and hence generate some
>> object files and other files in the process.  I don't want to include
>> these files in a .gitignore as they are named differently on different
>> systems.  Hence, I include them in my .git/info/exclude file, where I am
>> developing the module.  So now, unless I do the same thing for all
>> places I checkout the repo as submodule, I end up with the module
>> indicated as dirty after I compile it.  This is a bit inconvenient.
> 
> That being said:
> The .gitignore file supports shell globs.  Are the generated files
> created with names that are so different that some simple shell globs
> used in one or more .gitignore files couldn't cover them?

Under Linux I for example get .o files whereas under Windows I get .obj files. Of course I could put both in .gitignore, but I don't like to have to exclude more files than necessary it gives me a bad feeling of accidentally one day exclude something important, which has at occasions happened before. (For the same reason i don't usually put *~ in .gitignore, as I don't want to impose emacs on others, that might prefer a different editor, but that is a bit different from the case we have here.) Furthermore, list could start to grow with more systems and build chains with more intermediate files.

/Gustaf