From: Han-Wen Nienhuys <hanwen@google.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>, git <git@vger.kernel.org>
Subject: Re: reflog existence & reftable
Date: Fri, 23 Apr 2021 11:20:52 +0200 [thread overview]
Message-ID: <CAFQ2z_OGv3qNp9jaeuMij5gqv1MoOeb73zH9mOvikLs8dWvmmg@mail.gmail.com> (raw)
In-Reply-To: <xmqqim4fzier.fsf@gitster.g>
On Wed, Apr 21, 2021 at 6:55 PM Junio C Hamano <gitster@pobox.com> wrote:
> If there isn't, then we could do either one of these two things.
>
> (1) we could add "git reflog create <ref>" and the reftable can
> record the fact that "reflog exists for the ref, but no ref
> movement recorded yet". Then the condition C can be checked.
>
> (2) we could declare that there is no way to create an empty reflog
> supported across ref backends, and make the tests that rely on
> the "feature" conditional on REF_FILES prerequisite.
>
> I have no strong preference. In the early days I found the ability
> to limit which branches get logged convenient, so if reftable
> backend can learn the similar trick, we would want to go route (1)
> (the convenience largely came from the fact that there was no need
> to add one configuration item per branch, so I do not think we would
> want to bother with branch.<name>.reflog=bool configuration---that
> won't be an easy-to-use substitute). On the other hand, logs are
> useful, and dormant logs are not costing anything (other than holding
> onto stale objects we may no longer want), so it could be that it
> may not be as convenient as it used to be to be able to turn logs on
> only on selected refs, in which case approach (2) is fine.
Exactly, these are the two options I outlined in my original message.
Both can be made to work. I slightly prefer 2 (empty reflogs don't
exist, and make logging a global switch), because it is simpler to
understand and document. The divergence with the files backend itself
is extra complexity, though. Maybe we could deprecate the behavior and
always write reflogs in the files backend too.
--
Han-Wen Nienhuys - Google Munich
I work 80%. Don't expect answers from me on Fridays.
--
Google Germany GmbH, Erika-Mann-Strasse 33, 80636 Munich
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
next prev parent reply other threads:[~2021-04-23 9:21 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-21 10:02 reflog existence & reftable Han-Wen Nienhuys
2021-04-21 11:57 ` Ævar Arnfjörð Bjarmason
2021-04-21 16:55 ` Junio C Hamano
2021-04-23 9:20 ` Han-Wen Nienhuys [this message]
2021-04-23 14:07 ` Jeff King
2021-04-26 17:33 ` Han-Wen Nienhuys
2021-04-27 6:52 ` Junio C Hamano
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=CAFQ2z_OGv3qNp9jaeuMij5gqv1MoOeb73zH9mOvikLs8dWvmmg@mail.gmail.com \
--to=hanwen@google.com \
--cc=avarab@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/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 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).