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

[Ramkumar Ramachandra <artagnon@gmail.com>]

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

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