From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: Csaba Henk <csaba@lowlife.hu>, git@vger.kernel.org
Subject: Re: git symbolic-ref vs. reflog (vs. rebase)
Date: Fri, 29 Apr 2011 23:58:20 -0400 [thread overview]
Message-ID: <20110430035819.GA4673@sigill.intra.peff.net> (raw)
In-Reply-To: <7vk4ecvf2c.fsf@alter.siamese.dyndns.org>
On Fri, Apr 29, 2011 at 04:00:11PM -0700, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > I think every caller should be using "-m" these days. I know we can't
> > _require_ it for historical reasons. But shouldn't symbolic-ref always
> > write a reflog entry? Even something like "we changed and I can't tell
> > you why" to cover older scripts that call symbolic-ref?
>
> I think the particular instance Csaba saw in rebase may want to pass the
> reason why it flipped the HEAD.
Oh, definitely. I was thinking more for external scripts that we can't
fix.
> Flipping HEAD temporarily to another ref to do something, only to flip it
> back before giving the control back to the user, might be something a
> script may want to have a choice of not logging, so I am mildly negative
> on changing the command to unconditionally log empty entry without being
> told.
Yeah, that is a legitimate use case. But I suspect many scripts were
simply never updated after reflogs were introduced (or their authors)
were lazy, so they flip it once without a reflog, and then the next
well-behaved writer who comes along ends up writing a reflog entry that
shows a hole.
So it is a question of whether helping probably-broken users is worth
shutting off a legitimate use case. I also wonder how valuable that use
case is. As a user, I think I'd rather see _everything_ in the reflog,
even if the script-writer doesn't think it's important.
I don't know that it matters much in any case. We haven't had any bug
reports either way; and given the current behavior, one can always yell
at the script author to properly reflog.
> "update-ref" seems to write an empty entry even when not given an "-m"
> option, and we can view it as robbing a similar choice from the scripts.
> We might want to fix it. I dunno.
I'm inclined to wait until somebody actually wants it. In the meantime
it helps users of old and/or broken scripts by providing an additional
checkpoint of state that might otherwise be missing.
-Peff
next prev parent reply other threads:[~2011-04-30 3:58 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-29 15:03 git symbolic-ref vs. reflog (vs. rebase) Csaba Henk
2011-04-29 16:19 ` Junio C Hamano
2011-04-29 17:21 ` Csaba Henk
2011-04-30 4:13 ` Jeff King
2011-05-02 8:46 ` Csaba Henk
2011-05-27 20:13 ` [PATCH 1/2] rebase: create HEAD reflog entry when aborting Jeff King
2011-05-27 20:16 ` [PATCH 2/2] rebase: write a reflog entry when finishing Jeff King
2011-04-29 22:48 ` git symbolic-ref vs. reflog (vs. rebase) Jeff King
2011-04-29 23:00 ` Junio C Hamano
2011-04-30 3:58 ` Jeff King [this message]
2011-05-02 8:38 ` Csaba Henk
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=20110430035819.GA4673@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=csaba@lowlife.hu \
--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).