Re: [PATCH 1/3] checkout: describe_detached_head: remove 3dots after committish
- Date: Tue, 7 Nov 2017 23:25:02 -0000
- From: "Philip Oakley" <philipoakley@xxxxxxx>
- Subject: Re: [PATCH 1/3] checkout: describe_detached_head: remove 3dots after committish
From: "Ann T Ropea" <bedhanger@xxxxxx>
Thanks for all the feedback provided!
I'd like to summarise what consensus we have reached so far and
then propose a way forward:
* we'll use the term "ellipsis (pl. ellipses)" for what's
been referred to as "3dots", "n-dots", "many dots" and so
Using a consistent term for the *display* of shortened oid's is good.
* we would like to use ellipses when attached to SHA-1
values only for the purpose of specifying a symmetric
difference (as per gitrevisions(7))
The symetric difference (three-dots) is a specific Git *cli* notation that
is distinct from the use of ellipsis for displaying oid's
* the usage of ellipses as a "here we truncated something
longer" is a relic which should be phased out.
I think that is true.
To get there, preventing describe_detached_head from appending
an ellipsis to the SHA-1 values it prints is one important step.
This change does not cause any test to fall over.
The other important step is dealing with the "git diff --raw"
output which features ellipses in the relic-fashion no longer
It would appear that simplifying diff.c's diff_aligned_abbrev
routine to something like:
/* Do we want all 40 hex characters?
if (len == GIT_SHA1_HEXSZ)
/* An abbreviated value is fine.
return diff_abbrev_oid(oid, len);
does do the trick.
This change causes quite a few tests to fall over; however, they
all have truncated-something-longer-ellipses in their
raw-diff-output expected sections, and removing the ellipses
from there makes the tests pass again, :-)
The number of failures you report in the test suit suggests that someone
somewhere will be expecting that notation, and that we may need a
deprecation period, perhaps with an 'ellipsis' config variable whose default
value can later be flipped, though that leaves a config value needing
Junio should be able to better advise on his preferred approach.
If we can agree that this is a way forward, i'll create & send
v2 of the patch series to the mailing list (it'll include the
fixed tests) and we'll see where we go from there.