Petr Baudis <pasky@xxxxxxx> writes: >> If you are going to list 30 or so top contributors in 8 rows times 4 >> columns, because visually the columns are much more distinct than the >> rows, it makes the result look more sorted. This is the same reasoning >> hwo "git help --all" was fixed with 112d0ba (Make "git help" sort git >> commands in columns, 2005-12-18). > > Actually, this is strange for me: I would never think about reading git > help --all by rows, and I would never think about reading the authors > list by columns! It's difficult for me to point out why, possibly > because the authors list has less items per row and the items are longer > (and multi-word), but that's just a speculation. Maybe cultural > background (Japanese books are written in columns, right?) plays some > role too, I don't know. I do not think the default mode of "ls" output to tty (aka "ls -C") was invented by/for Japanese people. >> And for the "giving credit" purpose, I do not think truncating the list at >> 5 commits or less threshold, as suggested earlier and already done, makes >> much sense, either. > > The point here is that the list is awfully long and also can contain > a lot of duplicates or people with broken unicode, etc. - it gets hard > to maintain, and it makes the about page too long. I would be of course > fine with a tiny link at the bottom "(show all contributors)". Your "incentive to move up" argument suggests otherwise. Even if it takes efforts to maintain on somebody's part, it is worth to be inclusive, *IF* the purpose of that bottom list is to give credits to people. The list on the site originally was not utilizing .mailmap and I asked Scott to use it to merge duplicate entries, which he did. People whose names are misspelled and/or split will now have incentive to tell Scott about the problem so that they can clean up *their* own names, and Scott can help maintaining .mailmap and feed the changes to me. This is my ulterior motive behind this suggestion; I can outsource the maintenance of .mailmap to people who care about it more than myself. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
