On Mon, Jan 18, 2010 at 08:54, Gustaf Hendeby <hendeby@xxxxxxxxxx> wrote: > Jacob Helwig wrote: >> On Mon, Jan 18, 2010 at 07:30, Gustaf Hendeby <hendeby@xxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html