git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Jeff King <peff@peff.net>
To: Cornelius Weig <cornelius.weig@tngtech.com>
Cc: Junio C Hamano <gitster@pobox.com>, git@vger.kernel.org
Subject: Re: [PATCH v3 2/3] refs: add option core.logAllRefUpdates = always
Date: Tue, 31 Jan 2017 19:21:11 +0100	[thread overview]
Message-ID: <20170131182110.mothq33nhswlizsa@sigill.intra.peff.net> (raw)
In-Reply-To: <1e341485-6fb6-243a-0b27-4035789a6f2a@tngtech.com>

On Tue, Jan 31, 2017 at 03:00:33PM +0100, Cornelius Weig wrote:

> Concerning branches, I fully agree. For git-branch, the
> "--no-create-reflog" option does not make sense at all and should
> produce an error.
> 
> On the other hand, for tags it may make sense to override
> logAllRefUpdates=always. As tag updates come exclusively from
> force-creating the same tag on another revision, a reflog will actually
> not be created by accident.

Hmm. I think you could also see tag creation and update via "git fetch",
though only with explicit refspecs, I think, not tag-following.

So I think ultimately you'd need to use "git -c logallrefupdates=false"
if you want to override reflog options for all commands. A saner
interface would probably be put teaching the ref code to respect a
configured list of exceptions ("I do want reflogs for refs/tags/, but
not for refs/foo/"). But I don't think it's sensible for anybody to go
to the work of doing that, given that I haven't heard a single useful
reason for --no-create-reflog in the first place.

Personally, I'd be fine with leaving it in its current state as a known
bug that somebody may fix later, if they actually care. But if it is not
too hard to fix while we are all thinking about it, we can do that.

-Peff

  reply	other threads:[~2017-01-31 18:21 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-25  0:19 [PATCH] tag: add tag.createReflog option cornelius.weig
2017-01-25  5:06 ` Pranit Bauva
2017-01-25 18:00 ` Jeff King
2017-01-25 18:10   ` Junio C Hamano
2017-01-25 21:21   ` Cornelius Weig
2017-01-25 21:33     ` Jeff King
2017-01-25 21:43       ` Junio C Hamano
2017-01-25 22:56         ` Junio C Hamano
2017-01-25 23:40           ` Cornelius Weig
2017-01-26  1:16       ` [PATCH] refs: add option core.logAllRefUpdates = always cornelius.weig
2017-01-26  1:16         ` cornelius.weig
2017-01-26  3:35           ` Jeff King
2017-01-26 14:06             ` Cornelius Weig
2017-01-26 14:46               ` Jeff King
2017-01-26 22:31             ` [PATCH v2 1/3] config: add markup to core.logAllRefUpdates doc cornelius.weig
2017-01-26 22:31               ` [PATCH v2 2/3] refs: add option core.logAllRefUpdates = always cornelius.weig
2017-01-26 23:39                 ` Junio C Hamano
2017-01-26 22:31               ` [PATCH v2 3/3] update-ref: add test cases for bare repository cornelius.weig
2017-01-26 23:41                 ` Junio C Hamano
2017-01-26 23:24               ` [PATCH v2 1/3] config: add markup to core.logAllRefUpdates doc Junio C Hamano
2017-01-27 10:09                 ` [PATCH v3 " cornelius.weig
2017-01-27 10:09                   ` [PATCH v3 2/3] refs: add option core.logAllRefUpdates = always cornelius.weig
2017-01-30 21:58                     ` Junio C Hamano
2017-01-30 22:57                       ` Junio C Hamano
2017-01-31 13:16                         ` Cornelius Weig
2017-01-31 17:11                           ` Junio C Hamano
2017-01-30 23:37                       ` Jeff King
2017-01-31 14:00                         ` Cornelius Weig
2017-01-31 18:21                           ` Jeff King [this message]
2017-01-31 17:08                         ` Junio C Hamano
2017-01-31 20:28                           ` Cornelius Weig
2017-01-31 22:02                             ` Junio C Hamano
2017-01-27 10:09                   ` [PATCH v3 3/3] update-ref: add test cases for bare repository cornelius.weig

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=20170131182110.mothq33nhswlizsa@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=cornelius.weig@tngtech.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.
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).