On Sat, Dec 8, 2018 at 5:36 PM Junio C Hamano [off-list ref] wrote:
Matthew DeVore [off-list ref] writes:
quoted
In the codebase, "prune" is a highly overloaded term, and it caused me a
lot of trouble to figure out what it meant when it was used in the
context of path limiting. Stop using the word "prune" when we really
mean "path limiting."
path limiting is also used for two purposes. "pruning", which is to
cull the side branches that do not contribute the changes made to
the paths we are interested in, and showing only the changes to the
paths that match pathspec.
Thank you for the clarification re: side branches.
AFAIK, "prune" is also used to describe unreachable loose objects,
but that use is fairly isolated and have little risk of being
confusing too much. Are there other uses to make you consider it
"highly overloaded"?
This is what I found:
git prune - cull unreachable loose objects
git fetch --prune - remove remote-tracking refs that no longer exist
at source. Also note "--prune-tags" option
git notes prune - remove notes for non-existing/unreachable objects
git worktree prune - prunes "administrative" files
git prune-packed - removes loose objects that are also in pack files
git filter-branch --prune-empty - removes commits that become empty as
a result of rewriting.
It seems there are three general categories of the use of the term -
- to remove things from a view (e.g. in path limiting)
- to remove loose objects for efficiency (git prune, git prune-packed)
- to remove other things for either efficiency or to reduce cognitive
overhead (git worktree prune, git fetch --prune)
... and each of these categories has 2+ subcategories.
When I tried to figure out what "prune" and "prune_data" ("data" is
quite vague, so these two fields read like "prune_1" and "prune_2")
referred to in "revision.h", I basically did "grep -rn prune" and
looked through the results, but there were too many uses of the term
"prune" to pinpoint its meaning. If I used an IDE I might have been
able to "find usages" of struct revs's prune field, and I probably
*should have* done that, but I didn't have an IDE prepared and I
figured it wasn't important. Then an hour or so later I realized I was
still being confused by this term, and set out to figuring out what it
actually meant.
My gut feeling is that the result is not reducing "overloading" in a
meaningful way, and this change is not worth the churn, but it
depends on the answer to the above question.
Thanks.