Re: [GSoC][RFC] discussion about stashing with conflicts

[Thomas Gummerer <t.gummerer@gmail.com>]

On 04/08, Kapil Jain wrote:
> while understanding add_index_entry_with_check()
> i got to do_invalidate_path().
> 
> the commit hash for do_invalidate_path() function is
> `749864627c2d3c33bbc56d7ba0b5542af698cc40`
> 
> in the commit message it is explained that, cache-tree is used to
> store object names of index file objects and it is kept separate from
> index file because adding it would change index file format.
> 
> the part i couldn't understand is:
> "During various index manupulations, we selectively invalidate
> the parts so that the next write-tree can bypass regenerating
> tree objects for unchanged parts of the directory hierarchy."
> 
> what exactly does invalidating means here ?

FWIW, I don't think you need to understand cache-tree for the stash
GSoC project.  Your time is probably better spent taking what you
learned, and trying to make that into a proposal, as the application
period is coming to an end.

That said, since we are talking about a cache here, invalidating means
simply making part of the cache invalid, which means the caches
contents need to be re-calculated next time they are needed.

For the cache-tree in particular that means that we need to
re-calculate tree objects that have been invalidated, while we can
just re-use the ones that have not.

If you want to have a look at the cache-tree, you can use
't/helper/test-tool dump-cache-tree .git/index' from your locally
built git, which will dump the cache-tree that can be found
'.git/index'.  Compare the output of that command just after you did
'git reset --hard' on your repository (of course it needs some
contents), and after you modified some file, and added it to the index
using 'git add'.  In the latter case you will notice some directories
that are marked as 'invalid'.