Unmodified submodules shows up as dirty with 1.6.6.443.gd7346

Unmodified submodules shows up as dirty with 1.6.6.443.gd7346

[Gustaf Hendeby]

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


Anyone have an idea what is going on here?  (Related to the recent topic
by Jens Lehmann? cc:ed)  Unfortunately, I don't have the time to dig
into this right now, but I'll try to do it later tonight if the problem
remains.

/Gustaf

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

[Jacob Helwig]

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
>
>
> Anyone have an idea what is going on here?  (Related to the recent topic
> by Jens Lehmann? cc:ed)  Unfortunately, I don't have the time to dig
> into this right now, but I'll try to do it later tonight if the problem
> remains.
>
> /Gustaf
>

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).

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.

-Jacob

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

[Gustaf Hendeby]

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.
> 

Then the behavior of this feature differs from the one provided by
GIT-VERSION-GEN that is used as part of the git build process.  This is
not an argument itself, but personally, I don't like this behavior, and
think it should be reconsidered before inclusion into master.

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.

Am I the only one who uses submodules this way?  Is there a better way
to solve my problem that would provide a better work pattern in this case?

/Gustaf

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

[Jacob Helwig]

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.
>>
>
> Then the behavior of this feature differs from the one provided by
> GIT-VERSION-GEN that is used as part of the git build process.  This is
> not an argument itself, but personally, I don't like this behavior, and
> think it should be reconsidered before inclusion into master.
>
> 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.
>
> Am I the only one who uses submodules this way?  Is there a better way
> to solve my problem that would provide a better work pattern in this case?
>
> /Gustaf
>

I don't really deal with compiled code, when I use submodules, so any
time there's a new file in one of my submodules, it's almost certainly
a new library file that should make the submodule be considered
"dirty".  Even though the current behavior is what I'd expect, and
want for my uses, that doesn't mean it's not wrong for some other use
cases.

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?

-Jacob

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

[Junio C Hamano]

Gustaf Hendeby <hendeby@isy.liu.se> writes:

> ....  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,...

I don't have a strong opinion on the submodules part of your issue, but
the above part applies to projects with or without submodules, which I
have an opinion, and because it is different from what I used to teach
people, I think it is worth mentioning..

I used to say "Never place *~ (or *.swp) in .gitignore because they are
only useful to you who use Emacs (or vim); and do have *.o in .gitignore,
because everybody who compile your checkout would see it".

But I don't think the former is a right attitude.  My thinking these days
is that keeping these in .gitignore should not just be tolerated but
should be actively encouraged, unless the project may need to track paths
that match *~ or *.swp in the future,

If it is very unlikely that the project will ever track them, there is no
harm done [*1*], and it will help other people because they don't have to
add the same and common entries in their own .git/info/excludes file.

I am suspecting that your "these files ... are named differently on
different systems" may fall into the same category.  Your build may not
produce "frotz.linux" when compiled on a FreeBSD box (and "frotz.fbsd" on
a Linux box), but would it hurt more than it helps to list them in the
same .gitignore to cover both?


[Footnote]

*1* Once it starts doing so, un-ignoring a special case can be done
at that point in the history

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

[Gustaf Hendeby]

Jacob Helwig wrote:
> 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

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

[Jens Lehmann]

Am 18.01.2010 18:22, schrieb Junio C Hamano:
> I am suspecting that your "these files ... are named differently on
> different systems" may fall into the same category.  Your build may not
> produce "frotz.linux" when compiled on a FreeBSD box (and "frotz.fbsd" on
> a Linux box), but would it hurt more than it helps to list them in the
> same .gitignore to cover both?

If you keep source directories separate from directories for compiler
output you can easily simplify your .gitignore by negating it. So
instead of putting a line into the .gitignore for every file type you
do /not/ want, exclude everything in the build directory and add
exceptions for the files you /do/ want to track.

Then a .gitignore could look like this for building with VC6, VC8 and
Makefile based build systems:

path/to/build/directory/*
!*.dsw
!*.dsp
!*.sln
!*.vcproj
!Makefile

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

[Johannes Sixt]

Jacob Helwig schrieb:
> 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.

But isn't it a bug that a submodule is considered dirty just because an
untracked file appears?

-- Hannes

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

[Gustaf Hendeby]

Johannes Sixt wrote:
> Jacob Helwig schrieb:
>> 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.
> 
> But isn't it a bug that a submodule is considered dirty just because an
> untracked file appears?

I prefer the old behavior, and find the new one a bit unintuitive and I
suspect it will hit more people than just me once the change ends up on
master.  Unfortunately, the response yesterday pointed in the direction
of this being a wanted feature.  I think the change of behavior should
at least be mentioned in the release note.

/Gustaf

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

[Jacob Helwig]

On Mon, Jan 18, 2010 at 23:13, Johannes Sixt <j.sixt@viscovery.net> wrote:
> Jacob Helwig schrieb:
>> 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.
>
> But isn't it a bug that a submodule is considered dirty just because an
> untracked file appears?
>
> -- Hannes
>

I wouldn't consider it a bug, but that's specific to my use case of submodules.

At work, we're using them for shared Perl libraries between projects.
The only reason we have for creating new, untracked files in the
submodule is that we're adding new library code.  Having the submodule
show up as dirty for us is another safety towards not forgetting to
commit & push out this new code.

I agree that this isn't intuitive given how status normally handles
files in projects, but it makes sense (to me, anyway), when dealing
with library code.

Should this be the default behavior for everyone?  I can't say.  If
it's not, I would at least like it to be behavior that you can opt-in
to.

-Jacob

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

[Junio C Hamano]

Johannes Sixt <j.sixt@viscovery.net> writes:

> Jacob Helwig schrieb:
>> 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.
>
> But isn't it a bug that a submodule is considered dirty just because an
> untracked file appears?

My take while commenting on this series has been that we have been buggy
not to show submodule dirty when the end user may have files he forgot to
add, just like "git status" reminds them at the end.