Re: [PATCH 1/3] checkout: describe_detached_head: remove 3dots after committish

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
    forth

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.

But...

The other important step is dealing with the "git diff --raw"
output which features ellipses in the relic-fashion no longer
desired.

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)
return oid_to_hex(oid);

/* 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 support forever!

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.

--
Philip



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux