On Wed, Oct 16, 2024 at 02:52:56PM -0400, Taylor Blau wrote: > On Wed, Oct 16, 2024 at 11:07:02AM +0200, Wolfgang Müller wrote: > > On 2024-10-16 10:57, Patrick Steinhardt wrote: > > > Given that we do set `log.abbrev` I think we should be hitting code > > > paths in git-shortlog(1) that use it. `git shortlog --format=%h` for > > > example would use `log.abbrev`, wouldn't it? It would be nice to figure > > > out whether this can be made to misbehave based on which object hash we > > > have in the input. > > > > I did try this, but like I said, --format seems not supported when > > git-shortlog(1) is reading from stdin. It always outputs the same > > summary format, either grouped on authors or committers. This is not > > explicitly documented anywhere - the manual only says that "git shortlog > > will output a summary of the log read from standard input" and then goes > > on to document all the options with no mention of a difference in > > behaviour when reading from stdin. So I'm still not entirely convinced > > that this is impossible to trigger (also given the complexity of the > > argument parsing machinery), but I have not been able to find a way. > > Yeah, I think this is correct. For the purposes of this series, I think > that what Woflgang has done is sufficient on the testing front. > > As a nice piece of #leftoverbits, it would be appreciated to have a > patch that amends git-shortlog(1) to indicate that '--format' is ignored > when reading input from stdin. Yeah, I'm happy with the in-depth explanation that he gave and am fine with not adding a test. Patrick
