On Fri, Nov 05 2021, Junio C Hamano wrote: > Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes: > >> In a subsequent commit I'll change generate-cmdlist.sh to use C sort >> order, and without this change we'd be led to believe that that change >> caused a meaningful change in the output, > > What I found misleading in this sentence (which hasn't changed after > I pointed it out in the previous iterations) is that[...] I tried to clarify what you raised in the previous iteration with the new paragraph after the one you're quoting. I.e.: Note that this refers to the sort order of the lines in command-list.txt, a subsequent commit will also change how we treat the sort order of the "category" fields, but that's unrelated to this change. > command-list.txt is an input file, and if the sort order used in the > script that reads this to produce some other file as its output > changes, nobody will be "led to believe" anything. Not unless/until > which output file to look at and compare between revisions. I'd read your comment on the previous iteration as you being unclear on whether we were changing the sort order of lines in the file, or the category fields found within those lines. We don't sort the lines, and never have, just the fields, and within this series we stop doing that sorting (as it ends up in an OR'd bitfield, so it doesn't matter). > Is this talking about the order of entries in command-list.h file? > > Also, if the script sorts the input, whether it is in C locale or > other locale, it would not matter how the input originally is > sorted, as the input does not have duplicated entries to make sort > stability matter, no? This change is just to make this consistent for human editors. I think we re-sort this wherever we display this in git, whether that's via help.c or the completion powered by git.c.