git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Re: [PATCH v2 4/4] gc: remove broken symrefs
@ 2015-10-06 13:59 Johannes Schindelin
  0 siblings, 0 replies; 8+ messages in thread
From: Johannes Schindelin @ 2015-10-06 13:59 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Jeff King, git

Hi Junio,

On 2015-10-06 00:06, Junio C Hamano wrote:
> Johannes Schindelin <johannes.schindelin@gmx.de> writes:
> 
>> Oh, I appreciate your feedback. I am actually not all *that* certain
>> that removing the broken symref is the correct thing. It is this sort
>> of fruitful exchange that allows me to throw out an idea and be
>> relatively certain that something better will come out of v3 or v8 of
>> the patch series than what I had in mind.
>>
>> To be honest, the most important outcome is probably 2/4 -- which
>> should be enough to fix the issue reported by the Git for Windows
>> user. I could adjust the test so that it no longer insists that
>> origin/HEAD` be deleted, but still requires that `git gc` succeeds.
>>
>> I would have no problem to let this sit for a couple of days until
>> the final verdict.
> 
> ... and a few days have passed.  I am tempted to do the easy bits
> first, discarding the parts that both of us feel iffy for now
> without prejudice, keeping the first two commits with a bit of
> tweak.

I agree. And I just sent out v3 of the patch series.

Thanks,
Dscho

^ permalink raw reply	[flat|nested] 8+ messages in thread
* Re: [PATCH 4/4] gc: remove broken refs
@ 2015-09-25  0:08 Junio C Hamano
  2015-09-28 14:01 ` [PATCH v2 0/4] Fix gc failure when a remote HEAD goes stale Johannes Schindelin
  0 siblings, 1 reply; 8+ messages in thread
From: Junio C Hamano @ 2015-09-25  0:08 UTC (permalink / raw)
  To: Jeff King; +Cc: Johannes Schindelin, git

Jeff King <peff@peff.net> writes:

> For the same reasons as in my earlier responses, I think it's dangerous
> to remove broken refs (it makes a small corruption much worse). It seems
> reasonably sane to remove a dangling symref, though if we teach
> for_each_ref to gracefully skip them, then leaving them in place isn't a
> problem.

One thing I wondered was if we can reliably tell between a ref that
wanted to be a real ref that records a broken object name and a ref
that wanted to be a symbolic ref that points a bogus thing, and if
we can't, should we worry about it too much.  The former is more
serious, as the history behind the commit it wanted to but failed to
record is at risk of being pruned.

One case that is clearly safe is "ref: refs/heads/gone"; it is not
likely to be the result of attempting to write a real object name
gone bad by whatever filesystem corruption.  On the other hand, an
obviously problematic case is an empty file.  We cannot tell if the
"broken" ref used to anchor the tip of a real history (which is
about to be lost with Dscho's patch 1/4) or was merely pointing at
another ref (which will not harm the object database if ignored).

So the rule should be

    If resolve_ref_unsafe_1() says it is a symbolic ref, if
    check_ref_format() is OK with the ref it points at, and if that
    pointee is missing, then it is safe to skip.

All other funnies should trigger the safety.

The collection of "broken and can be removed" refs introduced by 3/4
may also have to take that into account, I think.

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2015-10-06 13:59 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-10-06 13:59 [PATCH v2 4/4] gc: remove broken symrefs Johannes Schindelin
  -- strict thread matches above, loose matches on Subject: below --
2015-09-25  0:08 [PATCH 4/4] gc: remove broken refs Junio C Hamano
2015-09-28 14:01 ` [PATCH v2 0/4] Fix gc failure when a remote HEAD goes stale Johannes Schindelin
2015-09-28 14:02   ` [PATCH v2 4/4] gc: remove broken symrefs Johannes Schindelin
2015-09-28 18:41     ` Junio C Hamano
2015-09-28 18:49       ` Junio C Hamano
2015-09-28 19:58         ` Johannes Schindelin
2015-10-05 22:06           ` Junio C Hamano
2015-09-28 19:03     ` Jeff King
2015-09-28 20:05       ` Johannes Schindelin

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).