Thread (1 message) 1 message, 1 author, 2017-06-02

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 ;-).
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help