Thread (5 messages) flat view 5 messages, 2 authors, 2016-06-15

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

From: Christoph Anton Mitterer <hidden>
Date: 2016-06-15 22:56:33

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.

Attachments

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help