{"thread":{"id":"23854","subject":"git-status and git-diff now very slow in project with a submodule","startedAt":"2010-05-20T10:01:02Z","lastAt":"2010-05-22T12:08:38Z","messageCount":16,"participants":["Andy Parkins","Stefan Naewe","Junio C Hamano","Michael J Gruber","Jens Lehmann","Nguyen Thai Ngoc Duy","Leo Razoumov","Andreas Schwab"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"141948","messageId":"ht3194$1vc$1@dough.gmane.org","threadId":"23854","inReplyTo":null,"subject":"git-status and git-diff now very slow in project with a submodule","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2010-05-20T10:01:02Z","receivedAt":"2010-05-20T10:01:02Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"Hello,\n\nI've just upgraded from 1.6.something to 1.7.1. All very nice.\n\nThe new submodule reporting is nice too; but I'd like to be able to turn it \noff :-)\n\nThe problem is that I have a (relatively) small project as the supermodule, \nand a linux kernel clone as a submodule and an ffmpeg clone as a submodule. \nNow I used to be able to do git-status or git-diff and it would be instant, \nit now takes a number of seconds to report. I guess (but don't know), that \nit is the detection of \"dirty\" status in the submodule's that is slowing \ndown the supermodule processing.\n\nI wouldn't like to see the feature go, because in almost all circumstances \nit is exactly right; however, I'd like to be able to turn off dirty \ndetection in submodules. Is this already possible, and I've just missed the \nconfiguration option?\n\nOne additional small point: why do untracked files in a submodule make the \nmodule dirty? I've often got a few \"temp.ps\" or \"debug.log\" or \n\"backtrace.log\" files lying around -- inappropriate to add to an ignore \nfile, but they don't make my working directory dirty. \"Dirty\" in a working \ndirectory means uncommitted changes to tracked files, why does it mean \nsomething different in a submodule?\n\n\n\nAndy\n-- \nDr Andy Parkins\nandyparkins@gmail.com\n"},{"id":"141954","messageId":"4BF50A92.3060209@atlas-elektronik.com","threadId":"23854","inReplyTo":"ht3194$1vc$1@dough.gmane.org","subject":"Re: git-status and git-diff now very slow in project with a submodule","fromName":"Stefan Naewe","fromEmail":"stefan.naewe@atlas-elektronik.com","sentAt":"2010-05-20T10:10:26Z","receivedAt":"2010-05-20T10:10:26Z","isPatch":false,"sender":{"key":"stefan.naewe@gmail.com","avatar":"https://avatars.githubusercontent.com/u/4468?v=4"},"body":"On 5/20/2010 12:01 PM, Andy Parkins wrote:\n> Hello,\n> \n> I've just upgraded from 1.6.something to 1.7.1. All very nice.\n> \n> The new submodule reporting is nice too; but I'd like to be able to turn it \n> off :-)\n> \n> The problem is that I have a (relatively) small project as the supermodule, \n> and a linux kernel clone as a submodule and an ffmpeg clone as a submodule. \n> Now I used to be able to do git-status or git-diff and it would be instant, \n> it now takes a number of seconds to report. I guess (but don't know), that \n> it is the detection of \"dirty\" status in the submodule's that is slowing \n> down the supermodule processing.\n> \n> I wouldn't like to see the feature go, because in almost all circumstances \n> it is exactly right; however, I'd like to be able to turn off dirty \n> detection in submodules. Is this already possible, and I've just missed the \n> configuration option?\n\nMaybe:\n\n git config status.submodulesummary false\n\n> One additional small point: why do untracked files in a submodule make the \n> module dirty? I've often got a few \"temp.ps\" or \"debug.log\" or \n> \"backtrace.log\" files lying around -- inappropriate to add to an ignore \n> file, but they don't make my working directory dirty. \"Dirty\" in a working \n> directory means uncommitted changes to tracked files, why does it mean \n> something different in a submodule?\n\nThat's IMHO a good point. I'd like to get an answer for that, too.\n\nRegards,\n Stefan\n-- \n----------------------------------------------------------------\n/dev/random says: ... Clinton excuse #15: Hey - I just do what the wife says\n"},{"id":"141959","messageId":"ht36u4$lo4$1@dough.gmane.org","threadId":"23854","inReplyTo":"4BF50A92.3060209@atlas-elektronik.com","subject":"Re: git-status and git-diff now very slow in project with a submodule","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2010-05-20T11:37:39Z","receivedAt":"2010-05-20T11:37:39Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"Stefan Naewe wrote:\n\n>> circumstances it is exactly right; however, I'd like to be able to turn\n>> off dirty\n>> detection in submodules. Is this already possible, and I've just missed\n>> the configuration option?\n> \n> Maybe:\n> \n> git config status.submodulesummary false\n\nHey! Thanks for the reply. Exactly the right option... except it doesn't work :-(\n\n$ git --version\ngit version 1.7.1\n$ git config status.submodulesummary\nfalse\n$ git status -uno\n# On branch master\n# Changed but not updated:\n# (use \"git add ...\" to update what will be committed)\n# (use \"git checkout -- ...\" to discard changes in working directory)\n# (commit or discard the untracked or modified content in submodules)\n#\n# modified: ffmpeg (modified content)\n#\nno changes added to commit (use \"git add\" and/or \"git commit -a\")\n\n\n\n\nAndy\n\n-- \nDr Andy Parkins\nandyparkins@gmail.com\n"},{"id":"141964","messageId":"7vy6fe7ldo.fsf@alter.siamese.dyndns.org","threadId":"23854","inReplyTo":"ht3194$1vc$1@dough.gmane.org","subject":"Re: git-status and git-diff now very slow in project with a submodule","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-05-20T13:28:35Z","receivedAt":"2010-05-20T13:28:35Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andy Parkins writes:\n\n> One additional small point: why do untracked files in a submodule make the \n> module dirty? I've often got a few \"temp.ps\" or \"debug.log\" or \n> \"backtrace.log\" files lying around -- inappropriate to add to an ignore \n> file, but they don't make my working directory dirty.\n\n\"They don't make my working directory dirty\" is something only you can\ndecide, until you tell git about that fact, isn't it?\n\nThe way to tell git about them is to use the ignore/exclude mechanism.\nWhy are they \"inappropriate to add to an ignore file\"? At least you could\nhave \"*.log\" in your personal exclude $GIT_DIR/info/exclude, no?\n\nAs to the not-working-configuration I don't remember the codepath well, so\nsorry but no answer from me right now.\n"},{"id":"141970","messageId":"4BF55ACD.3060009@drmicha.warpmail.net","threadId":"23854","inReplyTo":"ht36u4$lo4$1@dough.gmane.org","subject":"Re: git-status and git-diff now very slow in project with a submodule","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2010-05-20T15:52:45Z","receivedAt":"2010-05-20T15:52:45Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Andy Parkins venit, vidit, dixit 20.05.2010 13:37:\n> Stefan Naewe wrote:\n> \n>>> circumstances it is exactly right; however, I'd like to be able to turn\n>>> off dirty\n>>> detection in submodules. Is this already possible, and I've just missed\n>>> the configuration option?\n>>\n>> Maybe:\n>>\n>> git config status.submodulesummary false\n> \n> Hey! Thanks for the reply. Exactly the right option... except it doesn't work :-(\n> \n> $ git --version\n> git version 1.7.1\n> $ git config status.submodulesummary\n> false\n> $ git status -uno\n> # On branch master\n> # Changed but not updated:\n> # (use \"git add ...\" to update what will be committed)\n> # (use \"git checkout -- ...\" to discard changes in working directory)\n> # (commit or discard the untracked or modified content in submodules)\n> #\n> # modified: ffmpeg (modified content)\n> #\n> no changes added to commit (use \"git add\" and/or \"git commit -a\")\n\nYou see: No submodule summary here!\nTry setting the variable to true and see the difference. False is the\ndefault.\n\nGit needs to check the submodule in order to produce the \"modified\" line\neven when no summary is required. Stopping Git from looking at the\nsubmodule at all is impossible, I think. One could only hope that it\nstops scanning after the first modification.\n\nMichael\n"},{"id":"141973","messageId":"201005201817.05593.andyparkins@gmail.com","threadId":"23854","inReplyTo":"7vy6fe7ldo.fsf@alter.siamese.dyndns.org","subject":"Re: git-status and git-diff now very slow in project with a submodule","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2010-05-20T17:17:04Z","receivedAt":"2010-05-20T17:17:04Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Thursday 20 May 2010 14:28:35 Junio C Hamano wrote:\n\n> > One additional small point: why do untracked files in a submodule make\n> > the module dirty? I've often got a few \"temp.ps\" or \"debug.log\" or\n> > \"backtrace.log\" files lying around -- inappropriate to add to an\n> > ignore file, but they don't make my working directory dirty.\n> \n> \"They don't make my working directory dirty\" is something only you can\n> decide, until you tell git about that fact, isn't it?\n\nPerhaps I've misunderstood then; I have always understood that \"dirty\" was \nthe name we give to the state when tracked files have changes in the working \ndirectory. If not, then what word should be used to distinguish between \ntracked files unchecked in and untracked files?\n\nAnyhoo; I don't mind. Me starting a semantics debate isn't helpful is it?\n\n> The way to tell git about them is to use the ignore/exclude mechanism.\n> Why are they \"inappropriate to add to an ignore file\"? At least you\n> could have \"*.log\" in your personal exclude $GIT_DIR/info/exclude, no?\n\nI think you've taken me too literally; I was trying to get across the idea \nthat they are files that are made on the fly, and when I notice them they \njust get deleted.\n\nAlso, I don't want *.log, or *.ps -- neither of them is guaranteed to be an \nignore pattern. These throw away files have all sorts of names, made up on \nthe spot as I'm working, adding them to an ignore file is overkill from my \npoint of view.\n\n\n\nAndy\n-- \nDr Andy Parkins\nandyparkins@gmail.com\n"},{"id":"141975","messageId":"ht3sda$cvo$1@dough.gmane.org","threadId":"23854","inReplyTo":"4BF55ACD.3060009@drmicha.warpmail.net","subject":"Re: git-status and git-diff now very slow in project with a submodule","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2010-05-20T17:45:48Z","receivedAt":"2010-05-20T17:45:48Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"Michael J Gruber wrote:\n\n> You see: No submodule summary here!\n> Try setting the variable to true and see the difference. False is the\n> default.\n\nQuite so; I hadn't understood submodulesummary -- I just tried it when it \nwas suggested.\n\n> Git needs to check the submodule in order to produce the \"modified\" line\n> even when no summary is required. Stopping Git from looking at the\n\nI realise that -- what I was after is a return to the old behaviour -- under \nthe control of an option.\n\n> submodule at all is impossible, I think. One could only hope that it\n> stops scanning after the first modification.\n\n\"Impossible\" is a strong word for a behaviour that existed pre-1.7.\n\nIt's not that I want git not to look at the submodule at all; in fact it \ncertainly should for those cases when the submodule commit has changed, and \nI guess that a check for a dirty index is pretty quick too; but scanning the \nwhole submodule tree (which it has to do to find if anything was modified, \neven when nothing was modified) is a lot of extra time when the submodule is \nlarge. That extra time is inconvenient when you're working on a small \nproject that makes use of a large project as a submodule. (Most of my \npersonal use of submodule is embedding large projects that I want to be able \nto guarantee are at a particular version, but I don't really change them)\n\n\n\n\nAndy\n\n-- \nDr Andy Parkins\nandyparkins@gmail.com\n"},{"id":"141977","messageId":"4BF57635.9090409@web.de","threadId":"23854","inReplyTo":"ht3sda$cvo$1@dough.gmane.org","subject":"Re: git-status and git-diff now very slow in project with a submodule","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2010-05-20T17:49:41Z","receivedAt":"2010-05-20T17:49:41Z","isPatch":false,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 20.05.2010 19:45, schrieb Andy Parkins:\n> (Most of my\n> personal use of submodule is embedding large projects that I want to be able \n> to guarantee are at a particular version, but I don't really change them)\n\nBut to guarantee they are at a particular version they have to be checked\nfor local modifications (no matter if they happened accidentally or on\npurpose), no?\n"},{"id":"141978","messageId":"201005201901.49853.andyparkins@gmail.com","threadId":"23854","inReplyTo":"4BF57635.9090409@web.de","subject":"Re: git-status and git-diff now very slow in project with a submodule","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2010-05-20T18:01:49Z","receivedAt":"2010-05-20T18:01:49Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Thursday 20 May 2010 18:49:41 Jens Lehmann wrote:\n> Am 20.05.2010 19:45, schrieb Andy Parkins:\n> > (Most of my\n> > personal use of submodule is embedding large projects that I want to be\n> > able to guarantee are at a particular version, but I don't really\n> > change them)\n> \n> But to guarantee they are at a particular version they have to be checked\n> for local modifications (no matter if they happened accidentally or on\n> purpose), no?\n\nA valid point.\n\nSurely though in my own .git/config I can be allowed to tell git that I \ndon't care about that risk?\n\nI've got a top level module that used to diff/status instantly; now git \nscans an entire Linux kernel checkout and an entire ffmpeg checkout. \nPainful. I fully accept that it was my own choice to arrange my repository \nin this way, but in my defence, it was fine last week :-)\n\n\n\nAndy\n\n-- \nDr Andy Parkins\nandyparkins@gmail.com\n"},{"id":"141991","messageId":"7vbpca6uxi.fsf@alter.siamese.dyndns.org","threadId":"23854","inReplyTo":"201005201817.05593.andyparkins@gmail.com","subject":"Re: git-status and git-diff now very slow in project with a submodule","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-05-20T22:59:53Z","receivedAt":"2010-05-20T22:59:53Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andy Parkins writes:\n\n> Also, I don't want *.log, or *.ps -- neither of them is guaranteed to be an \n> ignore pattern. These throw away files have all sorts of names, made up on \n> the spot as I'm working, adding them to an ignore file is overkill from my \n> point of view.\n\nI've learned to give them names that begin with an unusual letter (in my\ncase, a colon or a plus sign), way before I started working on git, so the\nabove is not a very convincing argument at least to me.\n\nIn any case, I am a bit torn about this whole issue.\n\nOn one hand, scanning for untracked files are not about these *.log cruft,\nbut to catch mistakes that are caused by new paths that you forgot to add,\nand in that sense, uncommitted modifications to a path that happens to be\ntracked and a new path that you forgot to add have (semantically) similar\nchance of being a mistake that you might want to catch by running \"git\nstatus\".\n\nOn the other hand, adding new paths to an existing project is a rare\nevent, compared to modifications to existing paths (e.g. even for a\nproject as small and young as git.git, we have 10x as many revisions as we\nhave paths), so by definition the chance that you might break others'\nbuilds by forgetting to commit a new file is much smaller than forgetting\nto commit necessary changes to existing files.\n\nBut ideally you would want your tool to catch mistakes that are rarer, as\nyou would learn to avoid common mistakes on your own without help from\nyour tool over time.\n\nAt least we should be able to let the users say, with \"git status -uno\",\n\"I don't care about untracked and unignored paths; I don't make such a\nmistake to forget adding new paths\", and optimize the scanning of\nsubmodule directories taking advantage of that statement. Is there a\nfundamental reason why things shouldn't work that way, or is it just a\nbug in the current code?\n"},{"id":"142022","messageId":"4BF67710.30805@web.de","threadId":"23854","inReplyTo":"7vbpca6uxi.fsf@alter.siamese.dyndns.org","subject":"Re: git-status and git-diff now very slow in project with a submodule","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2010-05-21T12:05:36Z","receivedAt":"2010-05-21T12:05:36Z","isPatch":false,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 21.05.2010 00:59, schrieb Junio C Hamano:\n> At least we should be able to let the users say, with \"git status -uno\",\n> \"I don't care about untracked and unignored paths; I don't make such a\n> mistake to forget adding new paths\", and optimize the scanning of\n> submodule directories taking advantage of that statement. Is there a\n> fundamental reason why things shouldn't work that way, or is it just a\n> bug in the current code?\n\nIt works that way since 3bfc450. \"git status\" (and the diff family when\ncomparing against the work tree) forks a \"git status\" for each submodule\nthat is populated. If the status command in the superproject is started\nwith \"-uno\" the same option is used for the \"git status\" forked in the\npopulated submodules, so no checking for untracked files is done in that\ncase.\n\nBut that doesn't speed up that process much, as the tracked files inside\nthe submodules have to be checked for modifications anyway, no matter if\n\"-uno\" is used or not. Getting rid of the fork of a new \"git status\" by\nusing an alternate odb is on my to do list. Apart from gaining some time\nby avoiding the fork (which is a per-submodule-constant) we could terminate\nearly in case we find a modification (instead of continuing as the current\napproach does). But only dirty submodules would profit from that, a clean\nsubmodule won't be scanned much faster that way AFAICS.\n"},{"id":"142023","messageId":"AANLkTineTiY0blcQlTRWl-1Q-be6J-EOll2DMReKcUOF@mail.gmail.com","threadId":"23854","inReplyTo":"201005201901.49853.andyparkins@gmail.com","subject":"Re: git-status and git-diff now very slow in project with a submodule","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2010-05-21T12:36:14Z","receivedAt":"2010-05-21T12:36:14Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Thu, May 20, 2010 at 8:01 PM, Andy Parkins wrote:\n> On Thursday 20 May 2010 18:49:41 Jens Lehmann wrote:\n>> Am 20.05.2010 19:45, schrieb Andy Parkins:\n>> > (Most of my\n>> > personal use of submodule is embedding large projects that I want to be\n>> > able to guarantee are at a particular version, but I don't really\n>> > change them)\n>>\n>> But to guarantee they are at a particular version they have to be checked\n>> for local modifications (no matter if they happened accidentally or on\n>> purpose), no?\n>\n> A valid point.\n>\n> Surely though in my own .git/config I can be allowed to tell git that I\n> don't care about that risk?\n>\n> I've got a top level module that used to diff/status instantly; now git\n> scans an entire Linux kernel checkout and an entire ffmpeg checkout.\n> Painful. I fully accept that it was my own choice to arrange my repository\n> in this way, but in my defence, it was fine last week :-)\n\nSounds similar to the old \"slow lstat\" stuff. How about setting\nassume-unchanged bit on submodules? I don't know if it works. If it\ndoes not, maybe we could reuse the bit to ignore changes in\nsubmodules.\n-- \nDuy\n"},{"id":"142025","messageId":"AANLkTilctjct-a911H14XMnaBydYR1I6lPbEuFThTJ99@mail.gmail.com","threadId":"23854","inReplyTo":"7vy6fe7ldo.fsf@alter.siamese.dyndns.org","subject":"Re: git-status and git-diff now very slow in project with a submodule","fromName":"Leo Razoumov","fromEmail":"slonik.az@gmail.com","sentAt":"2010-05-21T12:52:13Z","receivedAt":"2010-05-21T12:52:13Z","isPatch":false,"sender":{"key":"slonik.az@gmail.com","avatar":null},"body":"On 2010-05-20, Junio C Hamano wrote:\n> Andy Parkins writes:\n>\n> > One additional small point: why do untracked files in a submodule make the\n> > module dirty? I've often got a few \"temp.ps\" or \"debug.log\" or\n> > \"backtrace.log\" files lying around -- inappropriate to add to an ignore\n> > file, but they don't make my working directory dirty.\n>\n>\n> \"They don't make my working directory dirty\" is something only you can\n> decide, until you tell git about that fact, isn't it?\n>\n> The way to tell git about them is to use the ignore/exclude mechanism.\n> Why are they \"inappropriate to add to an ignore file\"? At least you could\n> have \"*.log\" in your personal exclude $GIT_DIR/info/exclude, no?\n\nPlease, correct me if I am wrong, but I always thought that repo's\ndirty designation has to do with changed files _in_ the repo.\nUntracked files are _not_ in the repo and, as such, are irrelevant for\nrepo's clean/dirty status.\n\nSpeaking of .gitignore and untracked files. Explicitly mentioning all\nsuch untracked files in .gitignore is often unpractical. For example,\nduring build process some large projects autogenerate many temporary\n*.c *.h *.cpp files. Hunting all of them down and adding to\n.gitignore is a waste of time and one cannot use globs *.c *.h for\nobvious reasons.\n\nI think that it is consistent and logical to drop untracked files from\nrepo's dirty/clean decision process.\n\nI would be interested to know of any counter-example: that is, a\nuse-case where it makes logical sense to declare a repo dirty when it\ngets an untracked file not mentioned in .gitignore.\n\n--Leo--\n"},{"id":"142064","messageId":"m2tyq1qgxa.fsf@igel.home","threadId":"23854","inReplyTo":"AANLkTilctjct-a911H14XMnaBydYR1I6lPbEuFThTJ99@mail.gmail.com","subject":"Re: git-status and git-diff now very slow in project with a submodule","fromName":"Andreas Schwab","fromEmail":"schwab@linux-m68k.org","sentAt":"2010-05-21T17:54:25Z","receivedAt":"2010-05-21T17:54:25Z","isPatch":false,"sender":{"key":"schwab@linux-m68k.org","avatar":"https://avatars.githubusercontent.com/u/2175493?v=4"},"body":"Leo Razoumov writes:\n\n> Speaking of .gitignore and untracked files. Explicitly mentioning all\n> such untracked files in .gitignore is often unpractical. For example,\n> during build process some large projects autogenerate many temporary\n> *.c *.h *.cpp files. Hunting all of them down and adding to\n> .gitignore is a waste of time and one cannot use globs *.c *.h for\n> obvious reasons.\n\nYou can actually, since tracked files are never ignored.\n\nAndreas.\n\n-- \nAndreas Schwab, schwab@linux-m68k.org\nGPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5\n\"And now for something completely different.\"\n"},{"id":"142093","messageId":"4BF7C87F.3060207@web.de","threadId":"23854","inReplyTo":"m2tyq1qgxa.fsf@igel.home","subject":"Re: git-status and git-diff now very slow in project with a submodule","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2010-05-22T12:05:19Z","receivedAt":"2010-05-22T12:05:19Z","isPatch":false,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 21.05.2010 19:54, schrieb Andreas Schwab:\n> Leo Razoumov writes:\n> \n>> Speaking of .gitignore and untracked files. Explicitly mentioning all\n>> such untracked files in .gitignore is often unpractical. For example,\n>> during build process some large projects autogenerate many temporary\n>> *.c *.h *.cpp files. Hunting all of them down and adding to\n>> .gitignore is a waste of time and one cannot use globs *.c *.h for\n>> obvious reasons.\n> \n> You can actually, since tracked files are never ignored.\n\nHm, but that would mean newly added files would never show up again\n(the same .gitignore is used by the developers of that submodule when\nthey do work on it). So I wouldn't add *.c to .gitignore either ...\n\nBut I don't consider it a \"waste of time\" to get the .gitignore\nstraight for pretty much the same reasons I want to see no warnings\nduring compilation: So i can instantly see when something fishy\nmight be going on. I consider that a \"best practice\" instead.\n\nAnd for those projects where you can't or don't want to change the\n.gitignore: Just ignore when \"git status\" tells you a submodule has\n\"untracked content\" (it shows that information since 9297f7).\n"},{"id":"142094","messageId":"4BF7C946.1040000@web.de","threadId":"23854","inReplyTo":"AANLkTilctjct-a911H14XMnaBydYR1I6lPbEuFThTJ99@mail.gmail.com","subject":"Re: git-status and git-diff now very slow in project with a submodule","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2010-05-22T12:08:38Z","receivedAt":"2010-05-22T12:08:38Z","isPatch":false,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 21.05.2010 14:52, schrieb Leo Razoumov:\n> On 2010-05-20, Junio C Hamano wrote:\n> I would be interested to know of any counter-example: that is, a\n> use-case where it makes logical sense to declare a repo dirty when it\n> gets an untracked file not mentioned in .gitignore.\n\nFor submodules the presence of untracked files must be visible in the\nsuperproject. When new files are added to a submodule but the user\nforgot to commit them, the superproject might not even build at all\nwhen another developer clones the superproject. And yes, this is a\nreal-life use case from my dayjob.\n\nThe alternative to these broader definitions about when to declare a\nsubmodule dirty (new commits, modified content and untracked content)\nwould have been to handle all eight combinations of these states. In\nall relevant parts of the toolchain. Which seems pretty insane. So\nthe submodule shows up as modified; and all but the short outputs of\ndiff and status also tell you /why/ it is considered modified. So the\nuser can decide what to do about that.\n"}]}