[PATCH v2 0/2] fsck --connectivity-only --dangling
- Date: Mon, 4 Mar 2019 23:45:30 -0500
- From: Jeff King <peff@xxxxxxxx>
- Subject: [PATCH v2 0/2] fsck --connectivity-only --dangling
On Mon, Mar 04, 2019 at 11:26:01PM -0500, Jeff King wrote:
> > > So I sketched up what it might look like to just fix the bug (but kick
> > > in only when needed), which is below.
> > As the primariy purose of the --conn-only option being such, perhaps
> > we should have made --no-dangling the default when --conn-only is in
> > effect.
> Yes, perhaps. Though after thinking on this for a few days, I actually
> think there is no real reason not to just have --dangling do the right
> thing here (and we're still much faster than a full fsck, and not much
> slower than the current code unless you happen to have a large number
> of unreachable commits and trees).
> And then if the user says "--no-dangling", we can be even faster (i.e.,
> the same as the current code).
> We could also make "--no-dangling" the default for
> "--connectivity-only", though I do not have a strong feeling either way.
So here's a re-rolled series. The first patch just clarifies how
--connectivity-only works, since there are a few subtle points that came
up in this thread.
The second one is my fix from before. That lets us drop the initial
"explain why it doesn't work" documentation patch, though I did add a
note to the documentation pointing the user to --no-dangling.
[1/2]: doc/fsck: clarify --connectivity-only behavior
[2/2]: fsck: always compute USED flags for unreachable objects
Documentation/git-fsck.txt | 14 +++++++--
builtin/fsck.c | 62 ++++++++++++++++++++++++++++++++++++++
t/t1450-fsck.sh | 19 ++++++++++--
3 files changed, 90 insertions(+), 5 deletions(-)