"Shawn O. Pearce" <spearce@xxxxxxxxxxx> writes:
> Actually, the only time where it *isn't* a corruption is when its
> input to "git bundle create A.bdl ... -not $SOMEBADID" as that is
> the exact same thing as coming from the other side via send-pack.
And notice that it is about a nagative ref.
Another case you may use an object ID that may or may not be good and it
is not a corruption is when a Porcelain has an object ID obtained from
somewhere, and wants to know if it is safe to use the object. After
determining that the object itself exists (e.g. via "cat-file -t"),
you run
rev-list --objects $THAT_UNKNOWN_ID --not --all
to see if it is reachable from some of your own refs, or at least it is
connected to them without gaps. If it errors out while traversing, you
know it is bad; if it doesn't, you know you can merge one of the commits
reachable from your refs with it and put the result in your ref without
violating the ref-objects contract.
Notice that in this case, it is about a positive ref, and revision
machinery is set to notice the breakage.
So in that sense, the existing semantics is internally consistent. The
rules (I am not making up a new rule here, but just spelling out) are:
(1) You cannot just pick a random object that happens to exist in your
repository, traverse to the objects it refers to and expect
everything exists;
(2) If an object is reachable from any of your refs, however, you can
expect everything reachable from that object exists. Otherwise you
have a corrupt repository [*1*]).
(3) Your object store may have garbage objects that are not reachable
from any of your refs and it is normal.
(4) You can use random objects that may not be well connected as negative
revs to limit the range of revs (and optionally objects reachable
from them) listed by object traversal. If they are well connected,
they will affect the outcome, but it is not an error if they are
leftover cruft that is not connected to the positive ones you start
your listing traversal at.
[Footnote]
*1* You don't have to bring up grafts and shallow. People who know about
them know they are ways to hide or deliberately introduce this type of
corruption while keeping the system (mostly) working.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
