Re: gitk next/prev buttons

From: Marc Branchaud <marcnarc@xiplink.com>
Date: Oct 8, 2013, 20:45 UTC
Message-ID: <52546EE4.3070307@xiplink.com>
In-Reply-To: <20131008193618.GE9464@google.com>

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.