Re: GSoC draft proposal: Line-level history browser

From: Jonathan Nieder <jrnieder@gmail.com>
Date: Mar 23, 2010, 19:57 UTC
Message-ID: <20100323195724.GA1843@progeny.tock>
In-Reply-To: <41f08ee11003230823i1ca677b8q51b2413040c45c44@mail.gmail.com>

Bo Yang wrote:

> It traces the preimage of the minimum related diff hunk carefully, if
> there is any case that there are more than one commit intersect with
> the preimage, we will stop and ask the users to select which way to go
> on tracing.

That might be necessary, but I will admit that I suspect it to be harder to make useful. One of the very nice things about ‘git log’ is that it is easy to browse through history in a nonlinear way in a pager (by using a pager’s search functionality). The “backend” ‘git rev-list’ is easy to write scripts with, also because of its simple input and output.

If your program requires input from the user, how will it paginate its output? Most pagers expect the standard input to be available for input from the user.

One approach (I will not say it is a good one) to the problem of ambiguous origins for a line is to blame _both_ parents. That is, start following both lines of history in your revision walking. Perhaps higher-level tools like ‘git log --graph’ and gitk could visually represent the branched history you are showing.

Another approach is to just choose one parent automatically: for example, prefer the first parent, or assign some score representing the relatedness of each parent and choose the most related one.

Jonathan