# [PATCH 4/9] Discard "deleted" cache entries after using them to update the working tree 3 messages from 2008-02-04 to 2008-02-05. Participants: Daniel Barkalow, Johannes Schindelin. Thread: https://gitlist.dev/t/11877 ## Daniel Barkalow, 2008-02-04 18:35 Subject: [PATCH 4/9] Discard "deleted" cache entries after using them to update the working tree Message-ID: URL: https://gitlist.dev/e/alpine.LNX.1.00.0802041335470.13593%40iabervon.org ``` Way back in read-tree.c, we used a mode 0 cache entry to indicate that an entry had been deleted, so that the update code would remove the working tree file, and we would just skip it when writing out the index file afterward. These days, unpack_trees is a library function, and it is still leaving these entries in the active cache. Furthermore, unpack_trees doesn't correctly ignore those entries, and who knows what other code wouldn't expect them to be there, but just isn't yet called after a call to unpack_trees. To avoid having other code trip over these entries, have check_updates() remove them after it removes the working tree files. While we're at it, make the loop more obvious and skip passing in globals to a static function with only one caller. Signed-off-by: Daniel Barkalow --- unpack-trees.c | 16 +++++++++------- 1 files changed, 9 insertions(+), 7 deletions(-) diff --git a/unpack-trees.c b/unpack-trees.c index f462a56..40d4130 100644 --- a/unpack-trees.c +++ b/unpack-trees.c @@ -288,16 +288,16 @@ static void unlink_entry(char *name, char *last_symlink) } static struct checkout state; -static void check_updates(struct cache_entry **src, int nr, - struct unpack_trees_options *o) +static void check_updates(struct unpack_trees_options *o) { unsigned cnt = 0, total = 0; struct progress *progress = NULL; char last_symlink[PATH_MAX]; + int i; if (o->update && o->verbose_update) { - for (total = cnt = 0; cnt < nr; cnt++) { - struct cache_entry *ce = src[cnt]; + for (total = cnt = 0; cnt < active_nr; cnt++) { + struct cache_entry *ce = active_cache[cnt]; if (ce->ce_flags & (CE_UPDATE | CE_REMOVE)) total++; } @@ -308,14 +308,16 @@ static void check_updates(struct cache_entry **src, int nr, } *last_symlink = '\0'; - while (nr--) { - struct cache_entry *ce = *src++; + for (i = 0; i < active_nr; i++) { + struct cache_entry *ce = active_cache[i]; if (ce->ce_flags & (CE_UPDATE | CE_REMOVE)) display_progress(progress, ++cnt); if (ce->ce_flags & CE_REMOVE) { if (o->update) unlink_entry(ce->name, last_symlink); + remove_cache_entry_at(i); + i--; continue; } if (ce->ce_flags & CE_UPDATE) { @@ -374,7 +376,7 @@ int unpack_trees(unsigned len, struct tree_desc *t, struct unpack_trees_options error("Merge requires file-level merging"); } - check_updates(active_cache, active_nr, o); + check_updates(o); return 0; } -- 1.5.4 ``` ## Johannes Schindelin, 2008-02-05 01:25 Subject: Re: [PATCH 4/9] Discard "deleted" cache entries after using them to update the working tree Message-ID: URL: https://gitlist.dev/e/alpine.LSU.1.00.0802050123330.8543%40racer.site In-Reply-To: ``` Hi, On Mon, 4 Feb 2008, Daniel Barkalow wrote: > Way back in read-tree.c, we used a mode 0 cache entry to indicate that > an entry had been deleted, so that the update code would remove the > working tree file, and we would just skip it when writing out the index > file afterward. > > These days, unpack_trees is a library function, and it is still leaving > these entries in the active cache. Furthermore, unpack_trees doesn't > correctly ignore those entries, and who knows what other code wouldn't > expect them to be there, but just isn't yet called after a call to > unpack_trees. To avoid having other code trip over these entries, have > check_updates() remove them after it removes the working tree files. > > While we're at it, make the loop more obvious and skip passing in > globals to a static function with only one caller. After reading the code I understand what you mean. How about While at it, make the loop removing those entries more obvious, and avoid passing global variables as parameters to check_updates(): there is only one call site anyway. Ciao, Dscho ``` ## Daniel Barkalow, 2008-02-05 20:38 Subject: Re: [PATCH 4/9] Discard "deleted" cache entries after using them to update the working tree Message-ID: URL: https://gitlist.dev/e/alpine.LNX.1.00.0802042122400.13593%40iabervon.org In-Reply-To: ``` On Tue, 5 Feb 2008, Johannes Schindelin wrote: > Hi, > > On Mon, 4 Feb 2008, Daniel Barkalow wrote: > > > Way back in read-tree.c, we used a mode 0 cache entry to indicate that > > an entry had been deleted, so that the update code would remove the > > working tree file, and we would just skip it when writing out the index > > file afterward. > > > > These days, unpack_trees is a library function, and it is still leaving > > these entries in the active cache. Furthermore, unpack_trees doesn't > > correctly ignore those entries, and who knows what other code wouldn't > > expect them to be there, but just isn't yet called after a call to > > unpack_trees. To avoid having other code trip over these entries, have > > check_updates() remove them after it removes the working tree files. > > > > While we're at it, make the loop more obvious and skip passing in > > globals to a static function with only one caller. > > After reading the code I understand what you mean. How about > > While at it, make the loop removing those entries more obvious, > and avoid passing global variables as parameters to > check_updates(): there is only one call site anyway. It's the loop's flow control that I'm making more obvious (using a normal for loop instead of a while loop that counts down the number of entries while counting up the pointer to the entry under consideration). I'll clarify the message for the next version. -Daniel *This .sig left intentionally blank* ```