Re: [PATCH 1/2] diff: introduce --stat-lines to limit the stat lines

"Michael J Gruber" <git@drmicha.warpmail.net> writes:

Yeah, that was what I meant, but I think my mistake itself demonstrates how unintuitive "N lines each from the top and the bottom end" is.

It shouldn't be too difficult to divide the number given by the user by 2 and adjust only one end when the given number is even, but I am not sure if that is worth doing, or if it is even a good idea to have "..." in the middle to begin with; it would make it harder to notice that the list is elided than having the marker at the end.

But what problem are you trying to solve?

If it is just you do not want to see a huge list, shouldn't that option also be controlling how --summary is produced?

"Hide noise and show only a few from the top and from the bottom" makes sense when the items near the top and near the bottom are somehow more important than the others. Otherwise, "keep only a few from the top" should work just as well.

Usually, no single path is more important than the others, and even if there were a path that is more important than the others, people tend to arrange so that these more important paths come very early in the natural sort order (think "00_README"), so in that sense, items near the top could be more important than items elsewhere, while items near the bottom are unlikely to have higher nor lower importance than the remainder.

The bottom of a sorted list could become a bit more important than others in a narrow corner case that we would likely not care: when your change is only for paths whose names begin with 'a' through 'm', "show only a few from the top and from the bottom" would let you see that nothing between 'n' and 'z' was touched. I do not think it is an important piece of information to convey, though.

I designed merge.log (back then it was merge.summary) to show commits near the top because the person reading the log would be better served by seeing up to what change the merge integrated the topic branch.

A typical clean history of a topic branch tends to have necessary but uninteresting clean-up commits earier and the commits to complete the feature near the top. In the context of reading the merge itself, you care much more about why the merge was done (what the integration tree wanted out of the topic) than about how the topic progressed. Seeing the bottom (i.e. one commit above the fork point) may only be interesting for the person who is making a merge of his own topic branch, but it is not very useful for the integrator (the fork point itself may be a useful thing to know, though) nor for the reader of the history.

But the same "bottom could be a bit more important than others" argument can apply here, and I wouldn't oppose to a patch to change "merge.log" to show N-2 top entries, "...", and then a single bottom entry, when merging more than N+1 commits to your branch.

That approach would probably apply equally well to your --stat-count and covers the "the bottom is slightly more important than others" issue. It would go like this:

 - Show the first N-2 items unconditionally;

 - If you have shown N-2 items already, keep counting without
   showing, and remember the last two items you saw;

 - At the end of the loop,

   - if you didn't discard any and the last ones you remember comes
     immediately after the first N-2 items, just show them;

   - if you skipped any, show "... (%d items omitted)" and then
     show the last item.