[RFC] revision limiter in git-rev-list

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