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

From: Ramkumar Ramachandra <artagnon@gmail.com>
Date: Jun 16, 2013, 09:21 UTC
Message-ID: <CALkWK0ki9C9OL36b3j14C-mVMPy07Uj5FXcrfMZJs_g3zBRC9A@mail.gmail.com>
In-Reply-To: <7vmwqqkftv.fsf@alter.siamese.dyndns.org>

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.

Show 6 quoted lines

> An abbreviated unique SHA-1 you have today may not be unique
> tomorrow.  There is no reason to deliberately lose information
> (e.g. by using "Then, instead of the absolute minimum, let's record
> a bit more bytes" heuristics) when we record. The reflog recording
> code in checkout writes full 40-characters on purpose and there is
> no reason not to do so (i.e. the codepath that is the topic of 2/2).

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

  $ git checkout @^
  $ git reflog | head -n 1
  b1d94f2 HEAD@{2 seconds ago}: checkout: moving from checkout-dash to HEAD^

What does HEAD^ even mean? What guarantees that checkout-dash will not be something else tomorrow? If you want invariance, isn't that what the first field is for (b1d94f2)? As I understand it, the messages are purely to convey end-user information about the breadcrumb trail: they were later made semi-semantic (like the @{-N} parser using them).

Show 7 quoted lines

> Once we accept that design principle of not losing information when
> we do not have to, it naturally follows that the writing side should
> write full 40-hex, and also the reading side (i.e. the codepath that
> is the topic of 1/2) should make sure that it reads 40-hex and
> nothing else.  This also reduces the risk of a funny branch name
> that consists only of [0-9a-f] getting mistaken as an object name,
> but that is not the primary point.

As I already explained, I don't know what information loss you're talking about. And yes, I noticed advice.object_name_warning.

> So I am fairly strongly negative on both changes.

Okay, but please explain it for me.