git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Johannes Schindelin <johannes.schindelin@gmx.de>
To: Junio C Hamano <gitster@pobox.com>
Cc: Jeff King <peff@peff.net>, git@vger.kernel.org
Subject: Re: [PATCH v2 4/4] gc: remove broken symrefs
Date: Mon, 28 Sep 2015 21:58:08 +0200	[thread overview]
Message-ID: <da381393c0b6174cc07b4333308cf611@dscho.org> (raw)
In-Reply-To: <xmqqh9mecrap.fsf@gitster.mtv.corp.google.com>

Hi Junio,

On 2015-09-28 20:49, Junio C Hamano wrote:
> Junio C Hamano <gitster@pobox.com> writes:
> 
>> Johannes Schindelin <johannes.schindelin@gmx.de> writes:
>>
>>> When encountering broken symrefs, such as a stale remote HEAD (which can
>>> happen if the active branch was renamed in the remote), it is more
>>> helpful to remove those symrefs than to exit with an error.
>>
>> I think this depends on the perspective.  One side of me says that a
>> remote HEAD that points at refs/remotes/origin/topic that no longer
>> exists is still giving me a valuable information and it should take
>> a conscious action by the user to remove it, or evne better to
>> repoint it to a more useful place.  And from that point of view,
>> removing is not all that helpful.  Keeping them and not allowing
>> them to exit with an error would be a real improvement.
>>
>> On the other hand, I can certainly understand a view that considers
>> that such a dangling symbolic ref is merely a cruft like any other
>> cruft, and "gc" is all about removing cruft.
>>
>> It just feels to me that this is a bit more valuable than other
>> kinds of cruft, but maybe it is just me.
> 
> Sorry, it is a bad habit of me to send out without concluding
> remark, leaving the recipient hanging without knowing what the next
> step should be.
> 
> I meant to say that I plan to, and I indeed did, queue these 4
> without changes.  I am not opposed to the removal so strongly to
> reject [4/4].
> 
> The above comment was that I just do not know if this is the right
> thing to do, or it will be hurting users.

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.

Ciao,
Dscho

  reply	other threads:[~2015-09-28 19:58 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-24  9:13 [PATCH 0/4] Fix gc failure when a remote HEAD goes stale Johannes Schindelin
2015-09-24  9:13 ` [PATCH 1/4] gc: demonstrate failure with stale remote HEAD Johannes Schindelin
2015-09-24  9:13 ` [PATCH 2/4] pack-objects: do not get distracted by stale refs Johannes Schindelin
2015-09-24 17:03   ` Jeff King
2015-09-24  9:13 ` [PATCH 3/4] mark_reachable_objects(): optionally collect broken refs Johannes Schindelin
2015-09-24 17:56   ` Jeff King
2015-09-24  9:14 ` [PATCH 4/4] gc: remove " Johannes Schindelin
2015-09-24 17:57   ` Jeff King
2015-09-25  0:08     ` Junio C Hamano
2015-09-25  1:35       ` Jeff King
2015-09-28 14:01       ` [PATCH v2 0/4] Fix gc failure when a remote HEAD goes stale Johannes Schindelin
2015-09-28 14:01         ` [PATCH v2 1/4] gc: demonstrate failure with stale remote HEAD Johannes Schindelin
2015-09-28 14:01         ` [PATCH v2 2/4] pack-objects: do not get distracted by broken symrefs Johannes Schindelin
2015-09-28 14:01         ` [PATCH v2 3/4] mark_reachable_objects(): optionally collect " Johannes Schindelin
2015-09-28 14:02         ` [PATCH v2 4/4] gc: remove " 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 [this message]
2015-10-05 22:06                 ` Junio C Hamano
2015-09-28 19:03           ` Jeff King
2015-09-28 20:05             ` Johannes Schindelin
2015-10-06 13:57       ` [PATCH v3 0/2] Fix gc failure when a remote HEAD goes stale Johannes Schindelin
2015-10-06 13:58         ` [PATCH v3 1/2] gc: demonstrate failure with stale remote HEAD Johannes Schindelin
2015-10-06 13:59         ` [PATCH v3 2/2] pack-objects: do not get distracted by broken symrefs Johannes Schindelin
2015-10-07 17:45           ` Junio C Hamano
2015-10-08 19:15             ` Johannes Schindelin
2015-10-08 19:42               ` Junio C Hamano
2015-10-08 20:10                 ` Johannes Schindelin
  -- strict thread matches above, loose matches on Subject: below --
2015-10-06 13:59 [PATCH v2 4/4] gc: remove " Johannes Schindelin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=da381393c0b6174cc07b4333308cf611@dscho.org \
    --to=johannes.schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=peff@peff.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).