From: Junio C Hamano <gitster@pobox.com>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: Jeff King <peff@peff.net>,
Johannes Schindelin via GitGitGadget <gitgitgadget@gmail.com>,
git@vger.kernel.org
Subject: Re: [PATCH] reflog expire --stale-fix: be generous about missing objects
Date: Fri, 12 Feb 2021 11:35:58 -0800 [thread overview]
Message-ID: <xmqqy2ftuli9.fsf@gitster.c.googlers.com> (raw)
In-Reply-To: <nycvar.QRO.7.76.6.2102121702120.29765@tvgsbejvaqbjf.bet> (Johannes Schindelin's message of "Fri, 12 Feb 2021 17:04:08 +0100 (CET)")
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> Possibly the correct answer here is "turn off reflogs in new.git", but
>> they are sometimes useful, and things _mostly_ work (for history that
>> doesn't rewind, or where the rewound bits are specific to new.git). So
>> it's useful to be able to run something like "reflog expire --stale-fix"
>> to clear out the occasional problem.
>>
>> (A careful reader will note that objects mentioned only in the index
>> have a similar problem; but again, those tend to be local to new.git,
>> and don't exist at all in a server context).
>
> I want to add the experience with that half year during which `git gc`
> with worktrees was broken, as it would happily ignore the reflogs of the
> worktree-specific `HEAD`s, all except the one from the worktree from which
> `git gc` was run. That was some fun time, and `--stale-fix` was a life
> saver.
The option was invented for a specific case, but if its "fix"
applies for breakages caused by more recent bugs and user induced
actions, I would agree that that it gives us a good reason to keep
it around.
I have to wonder if the explanation in the documentation for the
option needs to be made less specific to the originally motivating
case, though.
Thanks.
prev parent reply other threads:[~2021-02-12 19:36 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-10 16:11 [PATCH] reflog expire --stale-fix: be generous about missing objects Johannes Schindelin via GitGitGadget
2021-02-10 20:30 ` Junio C Hamano
2021-02-11 11:10 ` Jeff King
2021-02-12 16:04 ` Johannes Schindelin
2021-02-12 19:35 ` Junio C Hamano [this message]
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqy2ftuli9.fsf@gitster.c.googlers.com \
--to=gitster@pobox.com \
--cc=Johannes.Schindelin@gmx.de \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.