Re: [RFC] revision limiter in git-rev-list

> "Marco Costalba" <mcostalba@gmail.com> writes:
>
> > Of course I really ignore any implementation difficult/feasibility issues ;-)
>
> I do not think your problem is ignoring difficulty/feasibility.
> The bigger problem is ignoring to describe the semantics of what
> you are proposing.
>

> For example:
>
> > 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
>
> Why does it give that?  Where is the HEAD in the example,

>
> > Note that the merge point b has been added implicitly as in
> > path limiter case.
>
> I do not think path limiter case adds anything.  A merge is
> shown if it touches the path in an nontrivial way, but otherwise
> it isn't.

> While I really do not think this belongs to rev-list, I suspect
> what you want is a command that takes a set of commits you are
> interested in and gives you an abbreviated topology across them.
> I think it might be a good thing to have in our toolset (didn't
> I say that already?).
>
> So your example would become:
>
>         Given this graph (and there may be other nodes before a or after
>         d or f):
>
>                   c---d
>                  /
>             a---b---e---f
>
>         the user is interested in A, D, and E.  Show an
>         abbreviated topology containing them.
>
> which would give you
>
>                   D
>                  /
>             A---B---E
>

>
> Unfortunately, your description is a bit too fuzzy to me, so I
> am making guesses as to what you really want.  For example,
> although you said "b is included because it is a merge", I
> strongly suspect you have cases where you would want to and not
> want to include a fork point or a merge point in the result,
> depending on the commits you are interested in.  If you are
> reducing this graph for A, H, and J:
>
>                 f---g
>                /     \
>               c---d---e---h
>              /
>         a---b---i---j
>
> I think you would want to see this as the result of graph
> reduction:
>
>               H
>              /
>         A---B---J
>
> instead of:
>
>               C---E---H
>              /
>         A---B---J
>
> That is, although e is a merge and c is a fork point, they do
> not bring anything interesting in the bird's eye view picture,
> and are filtered out.  However, b is a point where lines of
> development leading to H and J (two of the commits the user is
> interested in) forks, and it is interesting.
>
> Is this kind of graph reduction what you are after?
>
>