Re: [PATCH 0/2] Slightly prettier reflog message from checkout

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 17, 2013, 02:59 UTC
Message-ID: <7vtxkxigrb.fsf@alter.siamese.dyndns.org>
In-Reply-To: <CALkWK0ki9C9OL36b3j14C-mVMPy07Uj5FXcrfMZJs_g3zBRC9A@mail.gmail.com>

Ramkumar Ramachandra <artagnon@gmail.com> writes:

Show 8 quoted lines

> 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.