Re: [WIP 1/2] pack-objects: rename want_.* to ignore_.*
From: Junio C Hamano <hidden>
Date: 2017-06-02 03:46:02
Jonathan Tan [off-list ref] writes:
Currently, pack-objects conflates the concepts of "ignoring an object" and "including it in to_pack".
Hmph, that statement is a hard to read and agree to. I thought an ignored object that is not going to be packed is one that won't hit to_pack? I agree that "including to to_pack" and "actually appearing in the resulting pack" are three different things, though. Preferred base objects that are used when constructing a thin pack are thrown into to_pack because they need to participate in the delta base selection computation, but by definition they shouldn't be contained in the resulting pack (hence, nr_result is not incremented for them).
This is fine for now, but a subsequent commit will introduce the concept of an object that cannot be completely ignored, but should not be included in to_pack either. To separate these concepts, restrict want_found_object() and want_object_in_pack() to only indicate if the object is to be ignored. This is done by renaming these methods and swapping the meanings of the return values 0 and 1.
I am a bit confused by your reasoning. I guess it will become clearer if I knew exactly what you mean by "ignoring". It is not like "pretend as if it didn't exist in the rev-list --objects output we are working off of".
We also take the opportunity to use the terminology "preferred_base" instead of "excluded" in these methods. It is true that preferred bases are not included in the final packfile generation, but at this point in the code, there is no exclusion taking place - on the contrary, if something is "excluded", it is in fact guaranteed to be in to_pack.
This one I can understand.
Signed-off-by: Jonathan Tan <redacted> --- builtin/pack-objects.c | 50 +++++++++++++++++++++++++------------------------- 1 file changed, 25 insertions(+), 25 deletions(-)
Without understanding why this change is desirable, I can tell that overall this does not change the behaviour, which is good ;-).