Re: gc and repack ignore .git/*HEAD when checking reachability

From: Josh Triplett <josh@joshtriplett.org>
Date: Jul 8, 2016, 06:44 UTC
Message-ID: <20160708064448.GA18043@x>
In-Reply-To: <xmqq1t34oiit.fsf@gitster.mtv.corp.google.com>

On Thu, Jul 07, 2016 at 09:34:02PM -0700, Junio C Hamano wrote:

Show 7 quoted lines

> Josh Triplett <josh@joshtriplett.org> writes:
> > This could result in data loss, if a user expected that having an object
> > referenced from those places would protect it from pruning.
> 
> Yeah, luckily, nobody expects such.  I do not think any of our
> document says nothing other than HEAD like CHERRY_PICK_HEAD is
> reachability anchoring point; they are designed to be transient.

I can imagine at least one scenario that would result in data loss here: git pull a URL (not referenced via any ref other than FETCH_HEAD/MERGE_HEAD), get a merge conflict, get halfway through resolving it, set that repository aside for a while, do something that triggers a gc, then attempt to finish and commit.

Unlikely, but not impossible. Same reason the reachability logic looks at the index.

(I originally encountered this because I intended to add another HEAD-like ref in .git, so I started investigating the logic around such HEADs.)

Show 5 quoted lines

> Because they are designed to be transient, I do not think there is
> any downside (other than the initial start-up cost) to including
> them in reachability computation.  Because they are meant to be
> transient, the objects anchored by them would be reachable from
> other anchoring points anyway.

That sounds reasonable. And if they *do* end up taking any time to traverse, it's because they weren't reachable from other anchoring points, so taking the extra time to traverse them seems fine.

- Josh Triplett