From: Junio C Hamano <gitster@pobox.com>
To: Michael Haggerty <mhagger@alum.mit.edu>
Cc: "Stefan Beller" <sbeller@google.com>,
"Ronnie Sahlberg" <ronniesahlberg@gmail.com>,
"Jonathan Nieder" <jrnieder@gmail.com>,
"Nguyễn Thái Ngọc Duy" <pclouds@gmail.com>,
"git@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: [PATCH 6/8] reflog_expire(): ignore --updateref for symbolic references
Date: Thu, 12 Feb 2015 12:16:01 -0800 [thread overview]
Message-ID: <xmqqtwyqrim6.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <54DCD015.2080002@alum.mit.edu> (Michael Haggerty's message of "Thu, 12 Feb 2015 17:08:53 +0100")
Michael Haggerty <mhagger@alum.mit.edu> writes:
> This is a pretty exotic usage. I can't think of any real-life use case
> for using "--updateref" together with a symbolic reference. In our
> entire code base, "--updateref" is only used a single time, in
> "git-stash.sh", and that is always for "refs/stash", which is never a
> symbolic reference.
I have been wondering what the valid situation where --updateref is
a right thing to do on _any_ ref, be it a real one or a symbolic,
unless you are trying to manually fix a corrupted repository that
lack random objects left and right. We may expire old reflog
entries and make stale objects disappear, but even when we purge all
reflog entries by expiring anything that is older than a nanosecond
ago, I do not think of a situation where we see some reflog entry
surface as the "latest" entry that points at an object that is _not_
at the tip of the actual ref.
Except for the stash, of course, as you pointed out. We could drop
the tip (i.e. the latest) while keeping the other ones.
> "git-stash" itself is implemented in a very stylized
> way ("stylized" being a polite way of saying "bizarre"), and I doubt
> that there are many more users of this option in the wild, let alone
> "--updateref" together with a symbolic reference.
>
> So, honestly, I don't think it is worth the effort of deciding between 3
> vs. 4.
I agree with that assessment. We might even want to start thinking
about a good strategy to remove the --updateref option command,
which in turn would need to restructure how a stash is represented.
next prev parent reply other threads:[~2015-02-12 20:16 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-09 9:12 [PATCH 0/8] Fix some problems with reflog expiration Michael Haggerty
2015-02-09 9:12 ` [PATCH 1/8] write_ref_sha1(): remove check for lock == NULL Michael Haggerty
2015-02-10 22:52 ` Stefan Beller
2015-02-11 0:06 ` Jeff King
2015-02-09 9:12 ` [PATCH 2/8] write_ref_sha1(): Move write elision test to callers Michael Haggerty
2015-02-12 19:58 ` Junio C Hamano
2015-02-09 9:12 ` [PATCH 3/8] lock_ref_sha1_basic(): do not set force_write for missing references Michael Haggerty
2015-02-10 23:24 ` Stefan Beller
2015-02-11 0:05 ` Jeff King
2015-02-11 0:07 ` Stefan Beller
2015-02-12 12:09 ` Michael Haggerty
2015-02-09 9:12 ` [PATCH 4/8] reflog: fix documentation Michael Haggerty
2015-02-10 23:25 ` Stefan Beller
2015-02-09 9:12 ` [PATCH 5/8] reflog: rearrange the manpage Michael Haggerty
2015-02-10 23:42 ` Stefan Beller
2015-02-12 15:17 ` Michael Haggerty
2015-02-12 20:09 ` Junio C Hamano
2015-02-09 9:12 ` [PATCH 6/8] reflog_expire(): ignore --updateref for symbolic references Michael Haggerty
2015-02-11 0:44 ` Stefan Beller
2015-02-12 16:08 ` Michael Haggerty
2015-02-12 17:04 ` Stefan Beller
2015-02-12 20:16 ` Junio C Hamano [this message]
2015-02-12 21:54 ` Jeff King
2015-02-13 14:34 ` Michael Haggerty
2015-02-09 9:12 ` [PATCH 7/8] reflog_expire(): never update a reference to null_sha1 Michael Haggerty
2015-02-09 20:55 ` Eric Sunshine
2015-02-12 11:51 ` Michael Haggerty
2015-02-09 9:12 ` [PATCH 8/8] reflog_expire(): lock symbolic refs themselves, not their referent Michael Haggerty
2015-02-11 0:49 ` Stefan Beller
2015-02-11 22:49 ` Junio C Hamano
2015-02-11 23:25 ` Stefan Beller
2015-02-12 16:52 ` Michael Haggerty
2015-02-12 18:04 ` Stefan Beller
2015-02-13 16:26 ` Michael Haggerty
2015-02-13 17:16 ` Stefan Beller
2015-02-13 18:05 ` Junio C Hamano
2015-02-13 18:21 ` Stefan Beller
2015-02-13 18:26 ` Junio C Hamano
2015-02-13 18:32 ` Stefan Beller
2015-02-13 19:12 ` Junio C Hamano
2015-02-13 20:11 ` Michael Haggerty
2015-02-13 21:53 ` Junio C Hamano
2015-02-14 5:58 ` Michael Haggerty
2015-02-09 18:57 ` [PATCH 0/8] Fix some problems with reflog expiration Stefan Beller
2015-02-10 23:12 ` [PATCH] refs.c: get rid of force_write flag Stefan Beller
2015-02-12 15:35 ` Michael Haggerty
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=xmqqtwyqrim6.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=jrnieder@gmail.com \
--cc=mhagger@alum.mit.edu \
--cc=pclouds@gmail.com \
--cc=ronniesahlberg@gmail.com \
--cc=sbeller@google.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 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.