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

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