Jonathan Nieder wrote:
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.
What I would like to see (and may be too much for a GSOC project) is the
result to be a simplified commit graph with additional annotations of
the line range mappings that could be fed into something like a modified
gitk to view the _history_ of the lines of interest.
--
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