Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes: > In a later change I'm adding stress testing of the commit abbreviation > as it relates to git-blame and others, and initially thought that the > inability to extract full SHA-1s from the non-"--porcelain" output was > a bug. ... meaning that it is not actually a bug, as the output format other than porcelain is for human consumption? > --- a/Documentation/git-blame.txt > +++ b/Documentation/git-blame.txt > @@ -88,6 +88,11 @@ include::blame-options.txt[] > Instead of using the default 7+1 hexadecimal digits as the > abbreviated object name, use <n>+1 digits. Note that 1 column > is used for a caret to mark the boundary commit. This is outside the scope of this patch, but is the above 7+1 still current or do we need updating it for the (not so) recent change to auto-scale the default abbreviation width? > ++ > +Because of this UI design, the only way to get the full SHA-1 of the > +boundary commit is to use the `--porcelain` format. With `--abbrev=40` > +only 39 characters of the boundary SHA-1 will be emitted, since one > +will be used for the caret to mark the boundary. OK.
