I wonder if there some way to find the shortest path between two commits?
That is if there is a merge between the two commits I only want the merge
commit itself, not the potencially large list of commits that were merged.
I need that for commit notification scripts; I don't want to spam users
with too many emails and aggregating everything that came through a single
merge would be a reaonsable approach.
The problem is that it's entirely possible that no such path even
Two commits are not necessarily directly related, and asking for the
shortest path may involve having to go both backwards _and_ forwards in
history to get from one to the other. The most trivial case is
a <- head of tree
d <- root
where the shortest path between "b" and "c" is not really a well-defined
Now, _if_ you know that one of the commits is a direct descendant of the
other, a sensible path can be decided on, but even then the notion of
"shortest" is not obvious. Look at "a" vs "d" above - which path is the
shortest one? The one through "b" or the one through "c"? There's really
no way to tell them apart (you could select "first parent", but in more
complex graphs that might not be unambiguous either).
That said, and to finally answer your question: selecing _one_ short path
between two commits (if they are directly related) is certainly possible,
but no, we don't have anything like that available right now. It wouldn't
be hugely difficult to do an addition to git-rev-list to do so, though.
Can you describe your usage case? The operation really _isn't_ sensible in
general, so while I could add a flag to git-rev-list to only print out as
direct a chain as possible, I'd like to know that there is at least _one_
entirely sane usage for such a thing.