Johannes Schindelin wrote:
> 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.
> > 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.
> > 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
-
To unsubscribe from this list: 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
