We currently can run something like git-rev-list --topo-order --parents HEAD -- foo1.c foo2.c foo3.c And have in output a list of revisions that modify paths foo1.c, foo2.c and foo.3 For each revision we have also the corresponding pseudo-parents, i.e. the proper parents chosen among the revisions in output list. The idea is to extend this behaviour to also commit objects sha. As example, given the following revisions history: a b- | c | d e f We could add a new option --filtered so that git-rev-list --topo-order --filtered HEAD -- a d e Gives the following a b- | d e Note that the merge point b has been added implicitly as in path limiter case. This is a powerful and quite general option that can be use for a large and interesting number of cases. 1) Get the branch a given <sha> belongs git-rev-list --topo-order --parents --filtered HEAD -- <sha> branchList[0] branchList[1]... branchList[k-1] where branchList[] is the vector of branches of lenght k Searched branch is the one where sha appears as one of his parents. 2) Get nearest previous tag of a given <sha> git-rev-list --topo-order --parents -n1 --filtered <sha> -- <sha> tagList[0] tagList[1]... tagList[n-1] where tagList[] is the vector of tags of lenght n In output we have only one revision (see option -n1) that is <sha>, his parent(s) are the nearest tag(s). 3) Get tag/branch history with a sensible graph (using a GUI frontend) git-rev-list --topo-order --parents --filtered HEAD -- tagList[0] ... branchList[n-1] git-rev-list --topo-order --parents --filtered HEAD -- branchList[0] ... branchList[n-1] 4) Filter/find revisions according to a given search criteria (using a GUI frontend) git-rev-list --topo-order --parents --filtered HEAD -- matchList[0] ... matchList[n-1] where matchList[] is the vector of sha's matching a filter criteria and could be provided by a GUI frontend that already normally have filter capabilities. The plus here is to let frontend to draw a sensible graph of the resulting revisions. Probably there are other uses of this option that is very powerful because essentially it adds topological information to a given set of revisions. Of course I really ignore any implementation difficult/feasibility issues ;-) Marco - : 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