Re: [git-users] git clean vs git status re .gitignore
On Thu, Aug 21, 2014 at 10:16:08PM -0400, Paul Smith wrote: Does it seem incorrect to anyone else that git clean -X doesn't delete all the files in your workspace that are considered ignored by git status? Well, reading the man page for `git clean` like a lawyer (my emphasis below): -X Remove only *files* ignored by Git. This may be useful to rebuild everything from scratch, but keep manually created files. So, it could be argued it does what it says, it removes all *files* ignored by git, not ignored *folders*. I set up a small example that I hope matches your situation: % tree . └── SRC ├── foo.cxx └── SOMELIB.dir ├── Debug │ └── foo.cxx.o └── Release └── foo.cxx.o 4 directories, 3 files % cat .gitignore Debug/ Release/ % git status On branch master nothing to commit, working directory clean % git clean -ndX % git clean -ndx Would remove SRC/SOMELIB.dir/ So git doesn't want to delete the ignored *folders* Debug/ and Release/. Even more interestingly is the behaviour when we start ignoring '*.o' too: % print '*.o' .gitignore % git clean -ndX % git clean -ndx Would remove SRC/SOMELIB.dir/ That is, `git clean -ndX` won't remove ignored files located in ignored folders! I would argue that raising a bug on this is called for. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: mag...@therning.org jabber: mag...@therning.org twitter: magthe http://therning.org/magnus Goto labels should be left-aligned in all caps and should include the programmer's name, home phone number, and credit card number. -- Abdul Nizar pgpUKJ7A8G8pQ.pgp Description: PGP signature
Re: [git-users] git clean vs git status re .gitignore
On Fri, 2014-08-22 at 10:05 +0200, Magnus Therning wrote: On Thu, Aug 21, 2014 at 10:16:08PM -0400, Paul Smith wrote: Does it seem incorrect to anyone else that git clean -X doesn't delete all the files in your workspace that are considered ignored by git status? Well, reading the man page for `git clean` like a lawyer (my emphasis below): -X Remove only *files* ignored by Git. This may be useful to rebuild everything from scratch, but keep manually created files. So, it could be argued it does what it says, it removes all *files* ignored by git, not ignored *folders*. Yes, but that's what the -d option is for. You'll note that the -x option has similar language regarding files. I set up a small example that I hope matches your situation: Yes, that's it. So git doesn't want to delete the ignored *folders* Debug/ and Release/. Even more interestingly is the behaviour when we start ignoring '*.o' too: My take on this is that git clean is doing a top-down operation, and when it comes across a file that is not in .gitignore (SOMELIB.dir) it stops and doesn't go down any further. For git status on the other hand, it DOES continue to go into SOMELIB.dir and then due to .gitignore it ends up pruning out everything inside that directory, then it doesn't print the empty directory (since git status never shows empty directories). I would argue that raising a bug on this is called for. OK thanks for the analysis! -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [git-users] git clean vs git status re .gitignore
From: Paul Smith p...@mad-scientist.net Sent: Friday, August 22, 2014 12:41 PM Subject: Re: [git-users] git clean vs git status re .gitignore On Fri, 2014-08-22 at 10:05 +0200, Magnus Therning wrote: On Thu, Aug 21, 2014 at 10:16:08PM -0400, Paul Smith wrote: Does it seem incorrect to anyone else that git clean -X doesn't delete all the files in your workspace that are considered ignored by git status? Well, reading the man page for `git clean` like a lawyer (my emphasis below): -X Remove only *files* ignored by Git. This may be useful to rebuild everything from scratch, but keep manually created files. So, it could be argued it does what it says, it removes all *files* ignored by git, not ignored *folders*. Yes, but that's what the -d option is for. You'll note that the -x option has similar language regarding files. I set up a small example that I hope matches your situation: Yes, that's it. So git doesn't want to delete the ignored *folders* Debug/ and Release/. Even more interestingly is the behaviour when we start ignoring '*.o' too: My take on this is that git clean is doing a top-down operation, and when it comes across a file that is not in .gitignore (SOMELIB.dir) it stops and doesn't go down any further. For git status on the other hand, it DOES continue to go into SOMELIB.dir and then due to .gitignore it ends up pruning out everything inside that directory, then it doesn't print the empty directory (since git status never shows empty directories). I would argue that raising a bug on this is called for. OK thanks for the analysis! -- There's also been a couple of recent discussions on the git list about the 'git status' listings being sometimes 'confusing', if that was part of your cross checking. http://marc.info/?t=14073763172r=1w=2 http://marc.info/?l=gitm=140733746519948w=2 Also a while back (last year?) the gitignore processing was updated IIRC so that it stopped descending directories after negative patterns, so there may be some code conflicts about when an ignore is fully valid between the different commands. You may also be able to repeat the issue using the new idea of teach fast-export an --anonymize option http://marc.info/?l=gitm=140860449702537w=2 which could allow you to demonstrate your issue (though it may have too much anonymisation!) Philip -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [git-users] git clean vs git status re .gitignore
On Fri, Aug 22, 2014 at 07:41:46AM -0400, Paul Smith wrote: On Fri, 2014-08-22 at 10:05 +0200, Magnus Therning wrote: On Thu, Aug 21, 2014 at 10:16:08PM -0400, Paul Smith wrote: Does it seem incorrect to anyone else that git clean -X doesn't delete all the files in your workspace that are considered ignored by git status? Well, reading the man page for `git clean` like a lawyer (my emphasis below): -X Remove only *files* ignored by Git. This may be useful to rebuild everything from scratch, but keep manually created files. So, it could be argued it does what it says, it removes all *files* ignored by git, not ignored *folders*. Yes, but that's what the -d option is for. You'll note that the -x option has similar language regarding files. No, not quite, this is from the man page again: -d Remove untracked directories in addition to untracked files. So, again when reading it as a lawyer, the folder is not untracked, it's ignored. The behaviour of `git clean -dX` when hitting an ignored folder is therefore unspecified. As is the experience of every C programmer, unspecified stuff is a source of much trouble. So I'd say that's another reason to raising a bug ;) /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: mag...@therning.org jabber: mag...@therning.org twitter: magthe http://therning.org/magnus Code as if whoever maintains your program is a violent psychopath who knows where you live. -- Anonymous pgpBum_vN5qvM.pgp Description: PGP signature
Re: [git-users] git clean vs git status re .gitignore
On Fri, 2014-08-22 at 21:05 +0200, Magnus Therning wrote: On Fri, Aug 22, 2014 at 07:41:46AM -0400, Paul Smith wrote: On Fri, 2014-08-22 at 10:05 +0200, Magnus Therning wrote: So, it could be argued it does what it says, it removes all *files* ignored by git, not ignored *folders*. Yes, but that's what the -d option is for. You'll note that the -x option has similar language regarding files. No, not quite, this is from the man page again: -d Remove untracked directories in addition to untracked files. So, again when reading it as a lawyer, the folder is not untracked, it's ignored. The behaviour of `git clean -dX` when hitting an ignored folder is therefore unspecified. Hm. I think the wording in the man page is incorrect or at least too loose. It's not possible in Git to ever have a tracked directory; Git doesn't store directories per se. A directory comes into existence only because there's a tracked file in it. So, untracked directories is, at the level of lawyer-ese anyway, meaningless. However we can assume that they mean to say directories which contain no tracked files here. Which would give the behavior I want. I think. :-). As is the experience of every C programmer, unspecified stuff is a source of much trouble. So I'd say that's another reason to raising a bug ;) I've found some threads on the git mailing list from 2010 and 2012 about this issue. It doesn't seem like consensus was reached. I'm going to construct a followup for that list and try to push it forward. Cheers! -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [git-users] git clean vs git status re .gitignore
On Wed, 2014-08-20 at 06:50 +0200, Magnus Therning wrote: Is there a specific reason you aren't using a separate build directory? (AFAIU this is the convention for CMake.) Historical precedence. People are used to doing in-source builds and some of our scripting for making releases, etc. expects to find things in those places. I completely agree that it would be great to move to an out-of-source build as the default but that's a larger project. In any event, this question is more abstract, summed up by this: Does it seem incorrect to anyone else that git clean -X doesn't delete all the files in your workspace that are considered ignored by git status? How does `git clean -fdx` behave? It does clean up these files... plus more as below. I've never really understood the difference between -x and -X, but I've always used only -x and it behaves exactly the way I expect it to. According to the docs (and this seems true to me), -X removes all files matched by .gitignore (except, in my case, not) while -x removes all ignored files AND all untracked files [*]. The thing about -x is you could lose work; if you had a new file that you hadn't gotten around to git add'ing, or you had a log file that you still wanted to look at but wasn't matched by a .gitignore line, etc. then -x will delete it while -X does not. The -X flag only deletes things that you've explicitly marked (via .gitignore) as ignorable, but leaves things it isn't sure about (untracked files) alone. [*] Technically what it does is pretend there's no .gitignore file, so that all ignored files become untracked, then delete all untracked files. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [git-users] git clean vs git status re .gitignore
On Tue, Aug 19, 2014 at 10:06:23PM -0400, Paul Smith wrote: One of the platforms I need to build on is Windows and we're using cmake to generate MSVC project files. MSVC allows you to build one of a small number of different types of output, such as Debug, Release, etc. Additionally, we have many different targets that are built: one for each library, executable, unit test program, etc. The way MSVC (or cmake, I'm not sure) organizes the output is that for a source directory SRC and a target SOMELIB built for Debug for example, the object files will be: SRC/foo.cpp SRC/SOMELIB.dir/Debug/foo.obj Note that here only SRC and SRC/foo.cpp are actually part of the Git repository; the other directories/files are not tracked. Is there a specific reason you aren't using a separate build directory? (AFAIU this is the convention for CMake.) Now, adding all the target directories (SOMELIB.dir) to .gitignore individually is a big pain since there are so many. And adding *.dir to .gitignore seems like it might match some stuff that we might want. So, I added the type directories to .gitignore, like this: Debug Release (also, these directories are used by Mac OS Xcode so need to be ignored anyway). This works great for git status; it doesn't show the SOMELIB.dir directory as untracked because after the .gitignore stuff is through getting rid of files that is just an empty directory. However after some head-banging today I discovered that git clean -fdX (which is what I normally use to clean out workspaces) won't delete these files. Apparently git clean -X uses a different algorithm than git status for matching .gitignore contents and since SOMELIB.dir is not ignored, git clean skips over it rather than looking inside it for ignored files. So I had this situation where I had stale object files in my workspace and git status showed I had no untracked files, but git clean -fdX didn't clean up the stale object files. Does it seem incorrect to anyone else that git clean -X doesn't delete all the files in your workspace that are considered ignored by git status? How does `git clean -fdx` behave? I've never really understood the difference between -x and -X, but I've always used only -x and it behaves exactly the way I expect it to. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: mag...@therning.org jabber: mag...@therning.org twitter: magthe http://therning.org/magnus Perl is another example of filling a tiny, short-term need, and then being a real problem in the longer term. -- Alan Kay pgp4UkikVDciR.pgp Description: PGP signature
