Re: [PATCH 0/2] Add optional parameters to the diff option "--ignore-submodules"

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On Tue, 8 Jun 2010, Jens Lehmann wrote:

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

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.

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

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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]