Backport Git for Windows' gitk patches

[dscho]

Some of them hail from all the way back to 2012, and even the youngest is a week and a day shy of its second birthday.

These patches have been carried in Git for Windows, being ported patiently to every new Git version, mainly because the lack of activity on other gitk patches on the Git mailing list did not entice me to upstream them and see just how far I can stretch my frustration tolerance.

Until now! Now, gitk has an active maintainer and I could not be more delighted to contribute these patches so that the wider community can benefit from them.

[j6t]

All changes look good. Will pick them up.

[avih]

I'm wondering out loud whether there's an overlap between the commit here "gitk: unicode file names support", which does an explicit conversion from utf-8 in several places, and the first commit in #7 "Fixing file name encoding issues", which adds only one line:

encoding system utf-8

I can't judge whether it's an overlap because I don't know how to reproduce an issue which the commit here fixes (and then check whether the other commit also fixes it).

But at least as far as my reported test results go at #7, there's at least one issue which the commit here doesn't fix on Windows, but the commit at #7 does fix on Windows - the missing diff output when invoking gitk <japanese file name>.

[j6t]

@avih Sure, commit 5eb02dd does assume that file names are encoded in UTF-8, but it has been battle-tested in the Git-for-Windows distribution.

Let's continue the discussion about encoding system utf-8 in #7.

[avih]

I think the first commit windows: ... executables in worktree changes some level of indirection or form of encapsulation of the arguments or something along those lines.

In the new open wrapper, if I add puts stderr $args at the first line and also right before real_open, like so:

proc open {args} {
	puts stderr $args
	# sanitize args ...
	puts stderr $args
	uplevel 1 real_open $args
}

Then for one of the calls, which apparently uses multi-line stdin, the stdin argument prints differently, but I don't think stdin is supposed to change between the printouts:

{| git log --no-color -z --pretty=raw --show-notes --parents --boundary --stdin <<f3431b1756435a4bddb3627064c9ab34fbd54dd9\n--\nã‚ã„ã†.txt} r
{| D:/path/to/cmd/git.exe log --no-color -z --pretty=raw --show-notes --parents --boundary --stdin {<<f3431b1756435a4bddb3627064c9ab34fbd54dd9
--
ã‚ã„ã†.txt}} r

(ignore the string encoding issue, it's an unrelated bug)

stdin of the original arguments is printed with newlines as escape sequence \n, but at the modified arguments it's printed as a list with literal newlines.

I'm unable to judge whether these are 100% equivalent (or only equivalent for open?), but if not, then it might suggest a bug in some circumstances (or a fix of a bug...).