On 13-10-08 03:36 PM, Jonathan Nieder wrote:
>
> In a branchy history, it is possible for the next matching commit to
> actually be newer.
Chronologically, yes.
Gitk will often display a history like this (here the numbers represent
commit dates, so 1 is the oldest commit, and I've rotated this 90 degrees
clockwise from how gitk would display it):
--3--4-------5---
/
--------1--2
If commits 2 and 4 match, and the user is looking at commit 2, then the
"next" matching commit from 2 is 4, which is chronologically newer.
However, I still find it more intuitive to think of commit 4 as "older" than
commit 2, at least when using gitk. This is because in gitk the commits are
generally older as you go down the list. (When it comes to branches,
chronology hardly matters anyway. In fact, gitk could ensure that all
commits are displayed in strictly chronological order regardless of branches,
and such a display would be just as correct as what it currently shows
although it'd be less compact.)
A gitk user comes to expect older commits to be lower down in the display.
It's certainly not a hard-and-fast rule, but it's a general paradigm that works.
> I think the intent of the buttons is "find the
> next result, looking down or up in the list of commits in the upper
> pane". Is there some other wording that would convey this better?
The problem is, at least for me, that when I'm using gitk to browse the
history of changes to a file, I'll often want to see things that happened
before or after a certain point. Once I start thinking like that, gitk's
concepts of "next" and "prev" mix me up, because I want to see the next thing
that happened to the file but the "next" button doesn't take me there. The
chronological (dis)ordering that branches introduce doesn't trip me up as
much as the "next" and "prev" buttons.
M.
--
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