Re: [PATCH] filter-branch: rewrite only refs which were not excludedbythe options

> Johannes Schindelin wrote:
> 
> > On Tue, 24 Jul 2007, Johannes Sixt wrote:
> > 
> > > Johannes Schindelin wrote:
> > >
> > > > On Tue, 24 Jul 2007, Johannes Sixt wrote:
> > > >
> > > > > But there's another problem. Consider this history:
> > > > >
> > > > >    ---X--o--M         <- master
> > > > >              \
> > > > >           ...-o-...-o <- topic
> > > > >
> > > > > Then this (rather contrieved) command:
> > > > >
> > > > >    $ git-filter-branch -n $n master topic --not X
> > > > >
> > > > > If $n is small enough so that M is never rewritten, then
> > > > >
> > > > >    git rev-list -1 "$ref" $negatives
> > > > >
> > > > > still expands to non-empty even for 'master' (= M), which then
> > > > > incorrectly ends up in "$tempdir"/heads.
> > > >
> > > > Aaargh!  Of course!  Since I have to add --topo-order at the end.
> > > > Otherwise it makes no sense.
> > >
> > > No, that was no my point: In my example above, if n=1, `git rev-list -1
> > > "$ref" $negatives` evaluates to
> > >
> > >     $ git rev-list -1 "master" -n 1 ^X
> > >
> > > which returns M, even though M is not going to be rewritten.
> > > --topo-order changes nothing. The problem is that the -n is a relative
> > > restriction. --since is turned into --max-age, which is absolute,
> > > therefore, the test works as expected with --since.
> > 
> > So you think we have to say something like
> > 
> >         git rev-list "$ref" $negatives | grep "$ref" > /dev/null || continue
> > 
> > ?
> 
> No, doesn't help either.
> 
> We are talking about a case where there is more than one positive ref.
> We need not consider the -- sub/ case - it makes things just even more
> complicated. There are two different rev ranges to be considered:
> 
>   # (1) candidate range to be rewritten
>   $ git rev-list "$@"
> 
>   # (2) test if positive ref is in candidate range
>   $ git rev-list $ref $negatives