Thread (6 messages) flat view 6 messages, 4 authors, 2016-06-15

Re: [PATCH] Disallow '\' in ref names

From: Johannes Sixt <hidden>
Date: 2016-06-15 22:46:43

Andreas Ericsson schrieb:
Johannes Sixt wrote:
quoted
Andreas Ericsson schrieb:
quoted
Robin Rosenberg wrote:
quoted
This is asking for trouble since '\' is a directory separator in
Windows and thus may produce unpredictable results.
NAK. We allow / on unixy systems, and that's the path separator there.
Junio even makes extensive use of it to create per-contributor
namespaces for topic-branches.

Are you guessing this might be a problem in the future, or have you
actually run into it?
This is not possible on Windows:

$ git update-ref refs/heads/foo\bar HEAD
fatal: Unable to create '.git/refs/heads/foo\bar.lock': No such file or
directory

The problem is that git doesn't create the directory .git/refs/heads/foo
because the ref handling only mkdir()s directories that were split off
from the ref at forward-slashes.
Ok. Isn't the slash -> backslash conversion thing supposed to be done by
a macro? I seem to remember something about PATH_DELIM.
It is is_dir_sep(). This macro is only used with pathspec, not with refs.
Therefore, backslashes in refs enter git unaltered and cause havoc on
Windows because git internally only knows how to treat forward-slashes in
refs in a special way.

Note that using is_dir_sep() in refs is not a solution because then refs
that were read from the file system would be reported with a forward-slash.
quoted
The decision not to mangle command line arguments that are refs (on
Windows) was intentional. (We do mangle pathspec, i.e. we convert '\' to
'/'.) But back then I did not think about what should happen if a ref
contains a backslash.
But what about when locating directory cutoffs for mkdir() stuff?
I can't parse your statement. ;)

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