Subject: Re: Getting 'git log' (or something else) to show me the relevant sub-graph?

From: Michael J Gruber <[email-masked]>
Date: Tue, 20 Apr 2010 17:18:17 +0200

Johan Herland venit, vidit, dixit 20.04.2010 16:49:
> Hi,
> 
> Consider the following (simplified) history:
> 
> ---O---O---O---O---O---O---O---O---O---O---O---O---M2--H  <-- mainline
>     \                                             /
>      O---O---O---O---O---O---O---M1--D---E---F---G  <-- dev-branch
>               \                 /
>                O---O---A---B---C  <-- topic-branch
> 
> Now, assume that I have bisected my way through to 'A', and found that 
> it introduces some bug. Now, I'm interested in visualizing the path 
> that this bug "travelled" to get into "mainline", i.e. the following 
> sub-graph:
> 
>                           --M2--H  <-- mainline
>                            /
>         --M1--D---E---F---G  <-- dev-branch
>          /
> A---B---C  <-- topic-branch
> 
> In other words, I'm interested in the following log (with decorations):
> 
> H (mainline)
> M2
> G (dev-branch)
> F
> E
> D
> M1
> C (topic-branch)
> B
> A
> 
> I have unsuccessfully dug through the 'git log' documentation to figure 
> out if it can produce this log, so I'm now throwing the question to the 
> almighty knowledge of the mailing list...
> 
> Here are some of my closest attempts, so far:
> 
> - git branch --contains A
> 	gives me "topic-branch", "dev-branch" and "mainline", which is
> 	relevant, but incomplete.
> 
> - git log --oneline --decorate --graph A^..mainline
> 	gives me a log/graph where I can search for A and then use the graph
> 	to trace the way back up to "mainline", but it still displays a lot of
> 	uninteresting commits (ancestors of M1 and M2) that I have to
> 	disregard. Although this is ok once in a while, the problem is common
> 	enough (and the real-world graphs complicated enough), that I'd like a
> 	better solution, if possible.
> 
> I guess what I'm looking for is something similar to --first-parent, 
> except instead of the _first_ parent, it should follow the _relevant_ 
> parent, as far as the relationship between A and "mainline" is 
> concerned.
> 
> In set-theory terms I guess what I want is "that which is both an 
> ancestor of H, and a descendant of A (inclusive)", but I don't know how 
> to explain this to 'git log'.

This would require a reverse tree walker for the first half of that set
intersection. It would come in handy in many situations, but we don't
have it.

Mathematically speaking it is trivial to associate to a directed graph
the graph with opposite orientation. Then we could walk as usual...

But, in fact, we do not "walk then intersect", but the walker implements
the intersection, so having that other dag would not even help.

Maybe we can teach the walker to mark commits as uninteresting which do
not have A in their ancestry?

Michael