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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html