git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Ramkumar Ramachandra <artagnon@gmail.com>
Cc: Git List <git@vger.kernel.org>
Subject: Re: [PATCH 0/2] Slightly prettier reflog message from checkout
Date: Sun, 16 Jun 2013 19:59:52 -0700	[thread overview]
Message-ID: <7vtxkxigrb.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <CALkWK0ki9C9OL36b3j14C-mVMPy07Uj5FXcrfMZJs_g3zBRC9A@mail.gmail.com> (Ramkumar Ramachandra's message of "Sun, 16 Jun 2013 14:51:52 +0530")

Ramkumar Ramachandra <artagnon@gmail.com> writes:

> Junio C Hamano wrote:
>> I view the two codepaths touched by these patches the other way
>> around.
>
> I see.  Thanks for the early feedback.  I have some doubts.
>
>> An abbreviated unique SHA-1 you have today may not be unique
>> tomorrow.

> When did we guarantee that the messages written by the reflog are invariant?

That is not the point.  From the proposed log message for your 2/2:

  f855138: checkout: moving from bdff0e3a374617dce784f801b97500d9ba2e4705 to co-reflog
  f855138: checkout: moving from bdff0e3 to co-reflog

The "bdff0e3" may be a unique abbreviation to identify the commit
bdff0e3a374617dce784f801b97500d9ba2e4705 when the reflog entry was
written.  But the latter can become meaningless once you have an
unrelated commit in your history that shares the prefix.

That is the "deliberate loss of information" I saw in the proposal.
Recording full 40-hex does not have to worry about that issue; you
do not even have to argue "but in this case we do not even have to
have unique SHA-1, nobody uses it" vs. "some other codepaths you are
not aware of may want to take advantage and start using it".  In
other words, we will have one less thing we have to worry about.

      reply	other threads:[~2013-06-17  3:00 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-15 17:38 [PATCH 0/2] Slightly prettier reflog message from checkout Ramkumar Ramachandra
2013-06-15 17:38 ` [PATCH 1/2] sha1_name: stop hard-coding 40-character hex checks Ramkumar Ramachandra
2013-06-16 13:28   ` Phil Hord
2013-06-18  7:03     ` Ramkumar Ramachandra
2013-06-18 14:27       ` Junio C Hamano
2013-06-15 17:38 ` [PATCH 2/2] checkout: do not write full sha1 to reflog Ramkumar Ramachandra
2013-06-15 17:42 ` [PATCH 0/2] Slightly prettier reflog message from checkout Ramkumar Ramachandra
2013-06-16  1:24 ` Junio C Hamano
2013-06-16  9:21   ` Ramkumar Ramachandra
2013-06-17  2:59     ` 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=7vtxkxigrb.fsf@alter.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=artagnon@gmail.com \
    --cc=git@vger.kernel.org \
    /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).