Am 07.01.22 um 20:40 schrieb Junio C Hamano: > René Scharfe <l.s.r@xxxxxx> writes: > >>> I actually wonder if it results in code that is much easier to >>> follow if we did: >>> >>> * Introduce an "enum apply_symlink_treatment" that has >>> APPLY_SYMLINK_GOES_AWAY and APPLY_SYMLINK_IN_RESULT as its >>> possible values; >>> >>> * Make register_symlink_changes() and check_symlink_changes() >>> work with "enum apply_symlink_treatment"; >>> >>> * (optional) stop using string_list() to store the symlink_changes; >>> use strintmap and use strintmap_set() and strintmap_get() to >>> access its entries, so that the ugly implementation detail >>> (i.e. "the container type we use only has a (void *) field to >>> store caller-supplied data, so we cast an integer and a pointer >>> back and forth") can be safely hidden. >>> >> Or strsets -- we only need two. > > True. > > When we check a path, we make a single look-up of two bit in a > single hashtable but now we need two look-ups, but addition, removal > and renaming of a symlink would be rare enough to matter either way. Hmm, symlinks changes are rare, but this only affects the register phase (which should be noticeably slow for the string_list based code with its O(n*log(n)) lookup per registered symlink if there were a lot of them). But the final lookups are done for each path _component_, of any file type. I suspect that two lookups in (sparsely populated) hash tables are still fast enough. (At least I couldn't measure any difference with git apply and a patch between v2.33.0 and v2.34.0.) René
