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@xxxxxxxxxxxxxxx
Attachment:
signature.asc
Description: This is a digitally signed message part.
