How do I clear the directory cache

How do I clear the directory cache

[eschvoca]

Hi,

If I do a:

cg-commit
modifiy some files
cg-rm <modified files>
cg-add <a new file>
cg-rm <a unmodified file>

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

Re: How do I clear the directory cache

[Petr Baudis]

  Hello,

Dear diary, on Mon, Oct 17, 2005 at 04:20:42PM CEST, I got a letter
where eschvoca <eschvoca@gmail.com> told me that...
> If I do a:
> 
> cg-commit
> modifiy some files
> cg-rm <modified files>
> cg-add <a new file>
> cg-rm <a unmodified file>
> 
> 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 <an unmodified file>
	cg-rm <a new file>
	cg-add <modified files>

  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.

Re: How do I clear the directory cache

[eschvoca]

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 -<status_flag>  # 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] -<status_flag> # 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] -<status_flag> # 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.

Re: How do I clear the directory cache

[Junio C Hamano]

eschvoca <eschvoca@gmail.com> 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.

Re: How do I clear the directory cache

[Petr Baudis]

Dear diary, on Fri, Oct 21, 2005 at 05:23:28AM CEST, I got a letter
where eschvoca <eschvoca@gmail.com> 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 -<status_flag>  # 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] -<status_flag> # 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] -<status_flag> # 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.

Re: How do I clear the directory cache

[eschvoca]

On 10/21/05, Junio C Hamano <junkio@cox.net> wrote:
> eschvoca <eschvoca@gmail.com> 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.
>
>
>
>

Re: How do I clear the directory cache

[eschvoca]

On 10/21/05, Petr Baudis <pasky@suse.cz> wrote:
> Dear diary, on Fri, Oct 21, 2005 at 05:23:28AM CEST, I got a letter
> where eschvoca <eschvoca@gmail.com> 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 -<status_flag>  # 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] -<status_flag> # 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] -<status_flag> # 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.

Re: How do I clear the directory cache

[Linus Torvalds]

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

Re: How do I clear the directory cache

[Petr Baudis]

Dear diary, on Fri, Oct 21, 2005 at 10:40:07PM CEST, I got a letter
where eschvoca <eschvoca@gmail.com> told me that...
> On 10/21/05, Petr Baudis <pasky@suse.cz> wrote:
> > Dear diary, on Fri, Oct 21, 2005 at 05:23:28AM CEST, I got a letter
> > where eschvoca <eschvoca@gmail.com> told me that...
> > > cg-status -<status_flag>  # 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.

Re: How do I clear the directory cache

[eschvoca]

On 10/21/05, Petr Baudis <pasky@suse.cz> wrote:
> Dear diary, on Fri, Oct 21, 2005 at 10:40:07PM CEST, I got a letter
> where eschvoca <eschvoca@gmail.com> told me that...
> > On 10/21/05, Petr Baudis <pasky@suse.cz> wrote:
> > > Dear diary, on Fri, Oct 21, 2005 at 05:23:28AM CEST, I got a letter
> > > where eschvoca <eschvoca@gmail.com> told me that...
> > > > cg-status -<status_flag>  # 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.

Re: How do I clear the directory cache

[Petr Baudis]

Dear diary, on Sat, Oct 22, 2005 at 09:20:40PM CEST, I got a letter
where eschvoca <eschvoca@gmail.com> 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.