Re: [RFH] filter-branch: ancestor detection weirdness

From: Thomas Rast <trast@student.ethz.ch>
Date: Aug 12, 2008, 22:15 UTC
Message-ID: <200808130016.13948.trast@student.ethz.ch>
In-Reply-To: <7v7ialrk9a.fsf@gitster.siamese.dyndns.org>

Junio C Hamano wrote:

> Hmm, Dscho, perhaps we should take Thomas's patch as a "revert to 685ef54
> to fix breakage introduced by 813b473", and demonstrate the breakage with
> one of the new tests in his series?

Now you've lost me.

If you're saying 813b473 is at fault: it is not. The code I'm trying to fix came about in dfd05e38.

To see that the change in 813b473 is ok, you can simply run the following in git.git:

  diff -u <(git rev-list --reverse --parents --topo-order HEAD -- gitk) \
    <(git rev-list --reverse --topo-order HEAD -- gitk | while read commit
      do echo $(git rev-list -1 --parents $commit -- gitk); done)

The one thing that breaks down is (04c6e9e:git-filter-branch.sh:331)

        for p in $( (cd "$workdir"/../map; ls | sed "s/^/^/") |
                git rev-list $ref --boundary --stdin |
                sed -n "s/^-//p")

> I also _suspect_ that if you use --simplify-merges, the optimization
> made by 813b473 would still be usable even with path limiter.

It is always usable, if we are careful enough to use the same limiting arguments in all rev-lists involved.

> By the way, I am not sure if using --simplify-merges unconditionally is
> necessarily a good thing to do.

I think filter-branch would need a generic mechanism to pass arguments that affect commit selection. Passing '-- -- file' or '-- ^commit' to filter-branch --subdirectory-filter will probably break a few things, so it either needs to recognize those arguments itself or have a mechanism to specify them, if we want to support it. This also goes for the simplification mode.

- Thomas

-- 
Thomas Rast
trast@student.ethz.ch