Re: --abbrev-commit gives longer hash than necessary

2016-07-01 Thread Steffen Nurpmeso
Hmhm. Bryan Turner wrote: You now support git too. But say, is that you with the "stay away from the storage backend if you don't have a glue!", long ago on the Mercurial list??? Ha! See how important knowledge of an aggressively garbage-collected storage backend is. I always knew that! Ciao.

Re: --abbrev-commit gives longer hash than necessary

2016-07-01 Thread Steffen Nurpmeso
Hello Jeff! Jeff King wrote: |On Thu, Jun 30, 2016 at 09:38:45PM +0200, Steffen Nurpmeso wrote: |> For some time (currently with 2.9.0) know see that a single commit |> gives a longer hash than necessary, even though there is no |> ambiguity: |I don't know what your "git longca" alias is, b

Re: --abbrev-commit gives longer hash than necessary

2016-06-30 Thread Jeff King
On Thu, Jun 30, 2016 at 09:38:45PM +0200, Steffen Nurpmeso wrote: > For some time (currently with 2.9.0) know see that a single commit > gives a longer hash than necessary, even though there is no > ambiguity: > > ?0[steffen@wales ]$ git longca| > awk 'BEGIN{l7=0;l8=0}\ > /^[[:alnum:]]{7}

Re: --abbrev-commit gives longer hash than necessary

2016-06-30 Thread Bryan Turner
Steffen, Git commands generally have a 7 character minimum by default when abbreviating hashes, even if fewer characters are still (currently) unique. Per the documentation: core.abbrev Set the length object names are abbreviated to. If unspecified, many commands abbreviate to 7

--abbrev-commit gives longer hash than necessary

2016-06-30 Thread Steffen Nurpmeso
Hello, for your possible interest. For some time (currently with 2.9.0) know see that a single commit gives a longer hash than necessary, even though there is no ambiguity: ?0[steffen@wales ]$ git longca| awk 'BEGIN{l7=0;l8=0}\ /^[[:alnum:]]{7} /{++l7;next}\ /^[[:alnum:]]{8} /{++l8;pr