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

From: Johannes Sixt <j.sixt@eudaptics.com>
Date: Jul 24, 2007, 14:08 UTC
Message-ID: <46A607EB.BA31D7C5@eudaptics.com>
In-Reply-To: <Pine.LNX.4.64.0707241435290.14781@racer.site>

Johannes Schindelin wrote:

Show 17 quoted lines

> On Tue, 24 Jul 2007, Johannes Sixt wrote:
> > This worked:
> >
> > negatives=`git rev-parse --revs-only "$@" | while read line
> >       do
> >               case "$line" in
> >               $_x40) ;;
> >               *) echo "$line";;
> >               esac
> >       done`
> >
> > i.e. the closing parenthesis in the case arms together with the opening
> > $( made for a syntax error. The --revs-only did not hurt in my tests,
> > but you may have other reasons to remove it.
> 
> Funny.  AFAIR something similar worked here, all the time.  But I believe
> you... you're on MinGW, right?

No. filter-branch is a shell script. I don't have time to waste ;) It happens in bash 2.05b on Linux.

Show 19 quoted lines

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

Show 14 quoted lines

> > I think the decision whether a positive ref should be rewritten should
> > be postponed until the rewrite has completed. Because then we know for
> > certain which revs were treated and can pick the matching refs. We only
> > lose the check for the error "Which ref do you want to rewrite?"
> 
> No, that is not enough:
> 
>         A - B - C
> 
> B touches the subdirectory sub/.
> 
>         git filter-branch C -- sub/
> 
> will not rewrite C.

Fair enough.

-- Hannes