Thread (1 message) 1 message, 1 author, 2016-06-15

Re: [PATCH 13/16] prune: keep objects reachable from recent objects

From: Junio C Hamano <hidden>
Date: 2016-06-15 23:02:39

Jeff King [off-list ref] writes:
On Fri, Oct 03, 2014 at 02:47:57PM -0700, Junio C Hamano wrote:
quoted
With this patch applied, the system will not prune unreachable old
objects that are reachable from a recent object (the recent object
itself may or may not be reachable but that does not make any
difference).  And that is sufficient to ensure the integrity of the
repository even if you allow new objects to be created reusing any
of these unreachable objects that are left behind by prune, because
the reachability check done during prune (with this patch applied)
makes sure any object left in the repository can safely be used as a
starting point of connectivity traversal.
Your use of "safely" in the last sentence here made me think.

In a repository that has had this patch from the beginning, it should be
safe to traverse the unreachable but unpruned objects, because the
property of the repository we are trying to guarantee means that we will
have all of the referents.
...
Another case that may be of interest is to start a dumb HTTP commit
walker to fetch new history and kill it before it manages to
complete the graph and update the refs.  It has the same property as
running hash-objects to create an unconnected cruft object after you
got your repository into a "safe" state, but it would be a lot less
easier to blame the user for the resulting "breakage".

Perhaps the dumb commit walkers outlived their usefulness and we
should start talking about their deprecation and eventual removal at
a later version of Git?
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help