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 -- 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