Jens Lehmann [off-list ref] writes:
After thinking some time about peoples expectations and troubles
with the recursive scanning of submodules, I came up with this:
What about expanding the "--ignore-submodules" option of the git diff
family with three parameters:
--ignore-submodules=all : Same behavior as "--ignore-submodules",
submodules show never up as modified.
--ignore-submodules=untracked : Don't consider submodules as modified
when they only contain untracked files, but do if the commits in the
superproject are different or tracked content is modified.
--ignore-submodules=dirty : Don't consider submodules as modified
when their work tree is dirty, no matter why. This is the pre 1.7.0
behavior and doesn't recurse into submodules at all.
The first patch is just a resend of a test case rename, the second
contains the implementation.
To make that more useful the default could be controlled by the
.git/config or .gitmodules file. So you could have two submodules:
[submodule "sub1"]
path = sub1
url = /home/me/sub1.git/
ignore = dirty
[submodule "sub2"]
path = sub2
url = /home/me/sub2.git/
ignore = untracked
Where sub1 will not be scanned for work tree modifications by "git
diff" and "git status" and for sub2 any untracked files inside the
submodule will be ignored. And then "git status" should learn the
"--ignore-submodule" option too. With a fourth parameter "none" it
would be possible to override the defaults from the configuration
anyway you want.
Opinions?
The above outline (I haven't looked at the code) sounds sane. We might
even want to make untracked (or dirty) the default, if nothing is given
from the command line nor configuration.
I don't see a reason for patch 1/2, though.
Thanks.
Am 08.06.2010 19:28, schrieb Junio C Hamano:
The above outline (I haven't looked at the code) sounds sane. We might
even want to make untracked (or dirty) the default, if nothing is given
from the command line nor configuration.
Hm, as far as I interpreted the postings here, "none" should be a
reasonable default for most users because it protects them from errors
that are easy to make and hard to detect.
IIRC there are two main exceptions which want a different setting:
- Huge submodules which take a substantial portion of time to scan may
want "dirty" to avoid spending the extra time (at least until we have
an inotfiy daemon ;-).
- Submodules where the provider doesn't care or is not able to provide
a proper .gitignore for other reasons want "untracked" to avoid the
noise.
(Anything I missed?)
And these seem to fall into the category: If you are unlucky enough to
have one of these included in your superproject, configure these to use
"dirty" or "untracked" as appropriate. And AFAICT they are more the
exception than the rule so I came up with this proposal of a per
submodule configuration, so people won't have to turn off submodule
checking for all submodules because of a single special one.
I don't see a reason for patch 1/2, though.
Ok, I will drop that from the next round.
Hi,
On Tue, 8 Jun 2010, Jens Lehmann wrote:
Am 08.06.2010 19:28, schrieb Junio C Hamano:
quoted
The above outline (I haven't looked at the code) sounds sane. We might
even want to make untracked (or dirty) the default, if nothing is given
from the command line nor configuration.
Hm, as far as I interpreted the postings here, "none" should be a
reasonable default for most users because it protects them from errors
that are easy to make and hard to detect.
IIRC there are two main exceptions which want a different setting:
- Huge submodules which take a substantial portion of time to scan may
want "dirty" to avoid spending the extra time (at least until we have
an inotfiy daemon ;-).
Not only huge submodules. Thrashing the disk cache (e.g. by the sheer
number of submodules) is another reason. In my main project, the time for
a simple "git status" went up from unnoticable (<0.1 seconds AFAICT) to 45
seconds.
Let me repeat that. Fourty-five seconds. For a simple "git status".
According to me, the fact that nobody noticed can only be explained by the
lack of real submodule users. In particular, the people who invented the
submodules, and pushed them into "official" Git, never used it, but
precluded more appropriate solutions. I am not complaining, I am just
stating observations.
It comes back to my argument that developers should not have beefy
machines, lest they lose touch with the users and uses, and develop things
that closely skirt reality just so.
- Submodules where the provider doesn't care or is not able to provide
a proper .gitignore for other reasons want "untracked" to avoid the
noise.
While this is a valid scenario, I do not think that any user was hurt
by that case.
And these seem to fall into the category: If you are unlucky enough to
have one of these included in your superproject, configure these to use
"dirty" or "untracked" as appropriate. And AFAICT they are more the
exception than the rule so I came up with this proposal of a per
submodule configuration, so people won't have to turn off submodule
checking for all submodules because of a single special one.
I agree that the basic reason for the default to check for dirty and
untracked files is sound.
It is not your (Jens') fault that this does not integrate well into the
Git context, and that users of the submodule feature were punished that
heavily (just to reiterate, if anybody missed that number, the time on
"git status" -- or for that matter, "git diff" -- went up by >4500%. In
English words, that is four-thousand five hundred percent, and that is
just a lower bound).
So I would actually argue (being a real submodule user, not just an
imaginary one) that the default for dirty checking in the submodules
should stay.
quoted
I don't see a reason for patch 1/2, though.
Ok, I will drop that from the next round.
If I had not stopped caring about consistency in Git, I would strongly
contest this dropping.
Ciao,
Dscho