# How do I clear the directory cache 11 messages from 2005-10-17 to 2005-10-22. Participants: eschvoca, Petr Baudis, Junio C Hamano, Linus Torvalds. Thread: https://gitlist.dev/t/2123 ## eschvoca, 2005-10-17 14:20 Subject: How do I clear the directory cache Message-ID: <2b05065b0510170720n5333f03l1941e84c1288fc5d@mail.gmail.com> URL: https://gitlist.dev/e/2b05065b0510170720n5333f03l1941e84c1288fc5d%40mail.gmail.com ``` Hi, If I do a: cg-commit modifiy some files cg-rm cg-add cg-rm Then how do I get back and undo all of the cg-adds and cg-rms? I want cg-status to show the the changes from my commit and my current working tree. Thanks. e ``` ## Petr Baudis, 2005-10-20 08:59 Subject: Re: How do I clear the directory cache Message-ID: <20051020085931.GW30889@pasky.or.cz> URL: https://gitlist.dev/e/20051020085931.GW30889%40pasky.or.cz In-Reply-To: <2b05065b0510170720n5333f03l1941e84c1288fc5d@mail.gmail.com> ``` Hello, Dear diary, on Mon, Oct 17, 2005 at 04:20:42PM CEST, I got a letter where eschvoca told me that... > If I do a: > > cg-commit > modifiy some files > cg-rm > cg-add > cg-rm > > Then how do I get back and undo all of the cg-adds and cg-rms? I want > cg-status to show the the changes from my commit and my current > working tree. why can't you just do the following? cg-add cg-rm cg-add Hmm. Would it be non-marginally useful to offer something like cg-reset --adds-removals to just reset the index? (It's not --index because Cogito users aren't supposed to have to know what an "index" is.) -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ VI has two modes: the one in which it beeps and the one in which it doesn't. ``` ## eschvoca, 2005-10-21 03:23 Subject: Re: How do I clear the directory cache Message-ID: <2b05065b0510202023i62ab7c03uea1381d76535dcc7@mail.gmail.com> URL: https://gitlist.dev/e/2b05065b0510202023i62ab7c03uea1381d76535dcc7%40mail.gmail.com In-Reply-To: <20051020085931.GW30889@pasky.or.cz> ``` Yes, "cg-reset --adds-removals" is what I want (how do I do this with pure git?). I would like to clear/reset the index because I've screwed it all up. I don't think I can do as you suggested because of the way I got into this mess. I'm using git/cogito to version control my hard drive and I've been gradually adding more entries into the .gitignore file because some files change too frequently or I don't want them backed up. The OS modified a bunch of files, I cg-rm'd 1/4 of them, then I changed my mind and added them back, also did some genuine cg-adds, etc. and now I'm all confused (it's a whole hard drive). If other people are interested in doing this I can pass on the lessons I learned. What I found it git is amazingly fast! cg-status only takes a few seconds. I think there are some problems if you try to do: cd / cg-add -r usr cg-commit -m "take a long break" It seems that cg-add-ing and cg-commit-ing smaller chunks is faster than one big chunk. I think commands for the following should be added to cogito: cg-status - # list files with given status flag (without status flag in column 1) git-ls-files [--others|--deleted|etc] --exclude-per-directory=/.gitignore cg-add [-r] - # add files with a given status flag git-ls-files [--others|--deleted|etc] --exclude-per-directory=/.gitignore | while read i; do cg-add "$i; done cg-rm [-r] - # you get the idea. cg-addremove # recursively add new files, remove deleted files I use "while read i" so it will work with spaces in filenames. ``` ## Junio C Hamano, 2005-10-21 04:09 Subject: Re: How do I clear the directory cache Message-ID: <7vmzl34ikl.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vmzl34ikl.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <2b05065b0510202023i62ab7c03uea1381d76535dcc7@mail.gmail.com> ``` eschvoca writes: > Yes, ... is what I want (how do I do this with pure git?). How do you do *what* with pure git is something not clear to me, so let me try to rephrase you and see if I understood what you want correctly, in pure git terms: 0. Your last commit (.git/HEAD), your index file (.git/index) and the files in your working tree are in sync to begin with. 1. Then you do random changes in the working tree (add, modify, remove) and do git-update-index on them without making a commit. If your index file is fully in sync with your working tree, git-diff-files would say nothing after this. If you did git-update-index on some but not all, then git-diff-files would report unrecorded changes. 2. But you want to revert these changes to the index file. By "clearing the directory cache", you mean you want the index file to have what it had in step 0, but you want to keep what is on the filesystem intact. If that is what you want, then: $ git-read-tree HEAD $ git-update-index --refresh >/dev/null would reset the index to the tree recorded in your last commit. You can see that $ git diff --name-status --cached HEAD does not report any difference between HEAD and your index, while $ git diff --name-status shows the differences between your index and your working tree. HOWEVER, the index file does not record "intent to add", so you would not see files you added in step 1. mentioned in the output of the last command. ``` ## Petr Baudis, 2005-10-21 10:52 Subject: Re: How do I clear the directory cache Message-ID: <20051021105235.GF30889@pasky.or.cz> URL: https://gitlist.dev/e/20051021105235.GF30889%40pasky.or.cz In-Reply-To: <2b05065b0510202023i62ab7c03uea1381d76535dcc7@mail.gmail.com> ``` Dear diary, on Fri, Oct 21, 2005 at 05:23:28AM CEST, I got a letter where eschvoca told me that... > Yes, "cg-reset --adds-removals" is what I want (how do I do this with > pure git?). git-read-tree HEAD git-update-cache --refresh > I would like to clear/reset the index because I've screwed it all up. > I don't think I can do as you suggested because of the way I got into > this mess. > > I'm using git/cogito to version control my hard drive and I've been > gradually adding more entries into the .gitignore file because some > files change too frequently or I don't want them backed up. The OS > modified a bunch of files, I cg-rm'd 1/4 of them, then I changed my > mind and added them back, also did some genuine cg-adds, etc. and now > I'm all confused (it's a whole hard drive). Well, cg-status should show you what you effectively did, and then you could just do something like: cg-status -w | grep ^D | tr '\n' '\0' | xargs -0 cg-add cg-status -w | grep ^A | tr '\n' '\0' | xargs -0 cg-rm > If other people are interested in doing this I can pass on the lessons > I learned. > > What I found it git is amazingly fast! cg-status only takes a few > seconds. I think there are some problems if you try to do: > > cd / > cg-add -r usr > cg-commit -m "take a long break" > > It seems that cg-add-ing and cg-commit-ing smaller chunks is faster > than one big chunk. Interesting. I cannot spot anything which would bog it down in Cogito. Is both cg-add and cg-commit significantly slower? (That is, if it takes longer than sum of the smaller chunks.) Perhaps it's a cache issue, not everything from the chunk fits into your cache during cg-add, so cg-commit has to reread it from the disk. > I think commands for the following should be added to cogito: I'd prefer: > cg-status - # list files with given status flag (without > status flag in column 1) > git-ls-files [--others|--deleted|etc] --exclude-per-directory=/.gitignore All right, this might be useful. Implemented as cg-status -s '?' and such, thanks for the idea. > cg-add [-r] - # add files with a given status flag > git-ls-files [--others|--deleted|etc] > --exclude-per-directory=/.gitignore | while read i; do cg-add "$i; > done > > cg-rm [-r] - # you get the idea. > > cg-addremove # recursively add new files, remove deleted files I implemented the cg-reset --adds-removes option, but I don't feel comfortable with the cg-add change - just -r would be enough to add new files, and if you are in mess big enough, you can just cg-reset. It would be useful to make cg-rm symmetric to cg-add, though. Then you could do just cg-add -r . && cg-rm -r . and it would be equivalent to cg-addremove. > I use "while read i" so it will work with spaces in filenames. And break with leading spaces unless you modified $IFS properly. Note that those people having filenames starting by spaces are either seriously sick or script kiddies who just rooted you (or warez kiddies on your FTP server with anonymously-writable incoming). -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ VI has two modes: the one in which it beeps and the one in which it doesn't. ``` ## eschvoca, 2005-10-21 20:16 Subject: Re: How do I clear the directory cache Message-ID: <2b05065b0510211316j632c461apbb6f2f162e5fc7ef@mail.gmail.com> URL: https://gitlist.dev/e/2b05065b0510211316j632c461apbb6f2f162e5fc7ef%40mail.gmail.com In-Reply-To: <7vmzl34ikl.fsf@assigned-by-dhcp.cox.net> ``` On 10/21/05, Junio C Hamano wrote: > eschvoca writes: > > > Yes, ... is what I want (how do I do this with pure git?). > > How do you do *what* with pure git is something not clear to me, > so let me try to rephrase you and see if I understood what you > want correctly, in pure git terms: > > 0. Your last commit (.git/HEAD), your index file (.git/index) > and the files in your working tree are in sync to begin > with. > > 1. Then you do random changes in the working tree (add, modify, > remove) and do git-update-index on them without making a > commit. If your index file is fully in sync with your > working tree, git-diff-files would say nothing after this. > If you did git-update-index on some but not all, then > git-diff-files would report unrecorded changes. > > 2. But you want to revert these changes to the index file. By > "clearing the directory cache", you mean you want the index > file to have what it had in step 0, but you want to keep > what is on the filesystem intact. > > If that is what you want, then: > > $ git-read-tree HEAD > $ git-update-index --refresh >/dev/null Yes, this does exaclty what I want. Thankyou. > would reset the index to the tree recorded in your last commit. > You can see that > > $ git diff --name-status --cached HEAD > > does not report any difference between HEAD and your index, while > > $ git diff --name-status > > shows the differences between your index and your working tree. > > HOWEVER, the index file does not record "intent to add", so you > would not see files you added in step 1. mentioned in the output > of the last command. > > > > ``` ## eschvoca, 2005-10-21 20:40 Subject: Re: How do I clear the directory cache Message-ID: <2b05065b0510211340y9551767i53fe53c0dc14460a@mail.gmail.com> URL: https://gitlist.dev/e/2b05065b0510211340y9551767i53fe53c0dc14460a%40mail.gmail.com In-Reply-To: <20051021105235.GF30889@pasky.or.cz> ``` On 10/21/05, Petr Baudis wrote: > Dear diary, on Fri, Oct 21, 2005 at 05:23:28AM CEST, I got a letter > where eschvoca told me that... > > Yes, "cg-reset --adds-removals" is what I want (how do I do this with > > pure git?). > > git-read-tree HEAD > git-update-cache --refresh Thanks, it solves my problem. > > I would like to clear/reset the index because I've screwed it all up. > > I don't think I can do as you suggested because of the way I got into > > this mess. > > > > I'm using git/cogito to version control my hard drive and I've been > > gradually adding more entries into the .gitignore file because some > > files change too frequently or I don't want them backed up. The OS > > modified a bunch of files, I cg-rm'd 1/4 of them, then I changed my > > mind and added them back, also did some genuine cg-adds, etc. and now > > I'm all confused (it's a whole hard drive). > > Well, cg-status should show you what you effectively did, and then you > could just do something like: > > cg-status -w | grep ^D | tr '\n' '\0' | xargs -0 cg-add > cg-status -w | grep ^A | tr '\n' '\0' | xargs -0 cg-rm This is the right idea (and what I like to do) but you would have to remove the status flag (1st 2 chars) otherwise it gets included as part of the filename. I think most shells have some pretty small command length limits so i prefer to pipe into a loop rather than use xargs. > > If other people are interested in doing this I can pass on the lessons > > I learned. > > > > What I found it git is amazingly fast! cg-status only takes a few > > seconds. I think there are some problems if you try to do: > > > > cd / > > cg-add -r usr > > cg-commit -m "take a long break" > > > > It seems that cg-add-ing and cg-commit-ing smaller chunks is faster > > than one big chunk. > > Interesting. I cannot spot anything which would bog it down in Cogito. > Is both cg-add and cg-commit significantly slower? (That is, if it takes > longer than sum of the smaller chunks.) Perhaps it's a cache issue, not > everything from the chunk fits into your cache during cg-add, so > cg-commit has to reread it from the disk. I'll do some tests when I have time; currently this is just a gut feeling. > > I think commands for the following should be added to cogito: > > I'd prefer: > > > cg-status - # list files with given status flag (without > > status flag in column 1) > > git-ls-files [--others|--deleted|etc] --exclude-per-directory=/.gitignore > > All right, this might be useful. Implemented as cg-status -s '?' and such, > thanks for the idea. This is great but it would be easier to work with if there was another switch to turn off printing out the status flag. Otherwise you have to 'sed' or 'awk' out the status flag which is a pain, especially when files have spaces in them. > > cg-add [-r] - # add files with a given status flag > > git-ls-files [--others|--deleted|etc] > > --exclude-per-directory=/.gitignore | while read i; do cg-add "$i; > > done > > > > cg-rm [-r] - # you get the idea. > > > > cg-addremove # recursively add new files, remove deleted files > > I implemented the cg-reset --adds-removes option, but I don't feel > comfortable with the cg-add change - just -r would be enough to add new > files, and if you are in mess big enough, you can just cg-reset. It > would be useful to make cg-rm symmetric to cg-add, though. Then you > could do just > > cg-add -r . && cg-rm -r . > > and it would be equivalent to cg-addremove. Yes, that would be better -- more modular without being too much extra. Also, the "cg-add -r" exits when a file is bad. It would have saved me a few hours if it would keep not exit on a failure (and add the bad files to .gitignore ... but that is probably asking for too much). > > I use "while read i" so it will work with spaces in filenames. > > And break with leading spaces unless you modified $IFS properly. Note > that those people having filenames starting by spaces are either > seriously sick or script kiddies who just rooted you (or warez kiddies > on your FTP server with anonymously-writable incoming). Yeah, spaces are a nuisance and quite useless at the beginning of a file...CrossOver Office had some spaces in directory names. ``` ## Linus Torvalds, 2005-10-21 21:00 Subject: Re: How do I clear the directory cache Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.64.0510211354440.10477%40g5.osdl.org In-Reply-To: <2b05065b0510211316j632c461apbb6f2f162e5fc7ef@mail.gmail.com> ``` On Fri, 21 Oct 2005, eschvoca wrote: > > > > If that is what you want, then: > > > > $ git-read-tree HEAD > > $ git-update-index --refresh >/dev/null > > > Yes, this does exaclty what I want. Thankyou. Btw, if this ends up being something you do often (or more than once), it's best to use the "--reset" flag to git-read-tree. That will cause git-read-tree to still try to use any old usable entries in the old index, which most of the time means that 99% of the index will be up-to-date, and that in turn makes the index refresh _much_ faster. For small projects it doesn't matter, of course. In fact, those two lines can also be written simply as git reset which will do this, and more (in particular, it will also remove any sign of a partial merge-head). Linus ``` ## Petr Baudis, 2005-10-21 21:43 Subject: Re: How do I clear the directory cache Message-ID: <20051021214326.GJ30889@pasky.or.cz> URL: https://gitlist.dev/e/20051021214326.GJ30889%40pasky.or.cz In-Reply-To: <2b05065b0510211340y9551767i53fe53c0dc14460a@mail.gmail.com> ``` Dear diary, on Fri, Oct 21, 2005 at 10:40:07PM CEST, I got a letter where eschvoca told me that... > On 10/21/05, Petr Baudis wrote: > > Dear diary, on Fri, Oct 21, 2005 at 05:23:28AM CEST, I got a letter > > where eschvoca told me that... > > > cg-status - # list files with given status flag (without > > > status flag in column 1) > > > git-ls-files [--others|--deleted|etc] --exclude-per-directory=/.gitignore > > > > All right, this might be useful. Implemented as cg-status -s '?' and such, > > thanks for the idea. > > This is great but it would be easier to work with if there was another > switch to turn off printing > out the status flag. Otherwise you have to 'sed' or 'awk' out the > status flag which is a pain, especially when files have spaces in > them. Not such a huge pain, but if we already have -s... I added -n which does what you want. > Also, the "cg-add -r" exits when a file is bad. It would have saved > me a few hours if it would keep not exit on a failure (and add the bad > files to .gitignore ... but that is probably asking for too much). I don't like the idea of adding the files automagically to .gitignore, but it won't abort the whole operation because of them anymore. -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ VI has two modes: the one in which it beeps and the one in which it doesn't. ``` ## eschvoca, 2005-10-22 19:20 Subject: Re: How do I clear the directory cache Message-ID: <2b05065b0510221220r5c498c28lcb00d8846f156686@mail.gmail.com> URL: https://gitlist.dev/e/2b05065b0510221220r5c498c28lcb00d8846f156686%40mail.gmail.com In-Reply-To: <20051021214326.GJ30889@pasky.or.cz> ``` On 10/21/05, Petr Baudis wrote: > Dear diary, on Fri, Oct 21, 2005 at 10:40:07PM CEST, I got a letter > where eschvoca told me that... > > On 10/21/05, Petr Baudis wrote: > > > Dear diary, on Fri, Oct 21, 2005 at 05:23:28AM CEST, I got a letter > > > where eschvoca told me that... > > > > cg-status - # list files with given status flag (without > > > > status flag in column 1) > > > > git-ls-files [--others|--deleted|etc] --exclude-per-directory=/.gitignore > > > > > > All right, this might be useful. Implemented as cg-status -s '?' and such, > > > thanks for the idea. > > > > This is great but it would be easier to work with if there was another > > switch to turn off printing > > out the status flag. Otherwise you have to 'sed' or 'awk' out the > > status flag which is a pain, especially when files have spaces in > > them. > > Not such a huge pain, but if we already have -s... I added -n which does > what you want. Great. > > Also, the "cg-add -r" exits when a file is bad. It would have saved > > me a few hours if it would keep not exit on a failure (and add the bad > > files to .gitignore ... but that is probably asking for too much). > > I don't like the idea of adding the files automagically to .gitignore, > but it won't abort the whole operation because of them anymore. > I think it would make a lot of sense to print out an error to stderr if the file is bad (maybe you already do). From there it should be easy to capture stderr and construct .gitignore. Thanks for making cogito better for me and exceeding my expectations. ``` ## Petr Baudis, 2005-10-22 21:09 Subject: Re: How do I clear the directory cache Message-ID: <20051022210939.GR30889@pasky.or.cz> URL: https://gitlist.dev/e/20051022210939.GR30889%40pasky.or.cz In-Reply-To: <2b05065b0510221220r5c498c28lcb00d8846f156686@mail.gmail.com> ``` Dear diary, on Sat, Oct 22, 2005 at 09:20:40PM CEST, I got a letter where eschvoca told me that... > I think it would make a lot of sense to print out an error to stderr > if the file is > bad (maybe you already do). From there it should be easy to capture stderr > and construct .gitignore. Yes, we already do. -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ VI has two modes: the one in which it beeps and the one in which it doesn't. ```