Re: [PATCH] use refnames instead of "left"/"right" in dirdiffs

From: Christoph Anton Mitterer <mail@christoph.anton.mitterer.name>
Date: Mar 28, 2013, 12:46 UTC
Message-ID: <1364474776.11891.9.camel@heisenberg.scientia.net>
In-Reply-To: <20130327230715.GU2286@serenity.lan>

Hi John.

On Wed, 2013-03-27 at 23:07 +0000, John Keeping wrote:

> That's not going to work well on Windows, is it?

Uhm Winwhat? No seriously... doesn't dir-diff fail ther anway? The mkdir right now also uses mkpath with "/"... and I could read in it's documentation that it would automatically translate this, does it?

>  Anything with two dots
> in is already forbidden so we don't need to worry about that

Sure about this? I mean they're forbidden as refnames, but is this really checked within git-difftool before?

> ; I'm not
> sure we need to remove forward slashes at all

Mhh could be... seems that the cleanup happens via completely removing the $tmpdir path. And for the actual diff it shouldn't matter when there's a partentdir more.

>  until we consider the
> "commit containing" syntax ':/fix nasty bug' or 'master^{/fix bug}'.

Phew... don't ask me... I'm not that into the git source code... from the filename side, these shouldn't bother, only / an NUL is forbidden (in POSIX,... again I haven't checked win/mac which might not adhere to the standards).

> I'm more concerned with specifiers containing '^', '@', '{', ':' - see
> 'SPECIFYING REVISIONS' in git-rev-parse(1) for the full details of
> what's acceptable.

Mhh there are likely more problems... I just noted that $ldir/$rdir are used in a call to system() so... that needs to be shell escaped to prevent any bad stuff And if perl (me not a perl guy) interprets any such characters specially in strings, it must be handled either.

> At some point I think it may be better to fall back
> to the SHA1 of the relevant commit.

Think that would be quite a drawback...

Cheers, Chris.