From: Ramkumar Ramachandra Date: Sun, 16 Jun 2013 09:21:52 GMT Subject: Re: [PATCH 0/2] Slightly prettier reflog message from checkout Message-ID: 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. > 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.