Okay a sleepless might so I have some conclusions.
First of all any patched version needs to be based off 3.21 not 3.20
because the jump from 3.20 to 3.21 is really small and only affects
test files.
I extracted patch files for the suggested git commits. The total line
count is 492 though I am not quite sure what that tells you given the
context lines and other overheads.
Now the very first patch (on t/testargs.t) gets rejected.
There is only one change to t/testargs.t between version 3.21 and our
first patch. However that was part of a large merge on the 29th June
of changes by Chris Williams affecting about 30 files.
In conclusion to proceed with a patched 3.21 would require manual
analysis and application of the 10 patches. The second one looks
irrelevant to me.
Nicholas
Debian bug at v.nix.is wrote:
On Mon, Aug 23, 2010 at 16:00, gregor herrmann <gregoa@debian.org>
wrote:
I have no idea if this is enough or not; Nicholas and v.nix.is, what
do you think?
I didn't track down what commits exactly were pertinent to fixing
this, I just did a log from 3.21 to the master at the time and picked
all the pertinent ones.
The tests in the current master should test for the required behavior,
you can also e.g. check out Git's own git.git, run make and do cd t &&
prove t[0-9]*.sh to see if it works.
I'm on vacation now but I'd be happy to test out any patched version
around the end of the month to see if it fixes this issue.
I didn't see anything major in 3.22 though that should hold back
getting it into the next stable, and maintaining a 3.22 in Debian
instead of a patched version would probably be less painful in the
long run.