"Michael J Gruber" <git@xxxxxxxxxxxxxxxxxxxx> writes:
> On Fri, 29 Apr 2011 09:15 -0700, "Junio C Hamano" <gitster@xxxxxxxxx>
> wrote:
>> Also getting (N+1) "lines" output for specifying N feels very unnatural.
>>
> It's actually 2*(N+1): The first and last N, plus the "..." line.
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?
> With "count" I would expect to see the first N lines/items. That's even
> simpler to do. Do you think that makes more sense then head+tail?
"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.
--
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