Re: [PATCH 1/1] mingw: only test index entries for backslashes, not tree entries
- From
Johannes Schindelin <johannes.schindelin@gmx.de>
- Date
- Jan 4, 2020, 21:29 UTC
- Message-ID
- <nycvar.QRO.7.76.6.2001042225080.46@tvgsbejvaqbjf.bet>
- In-Reply-To
- <20200104015749.GE130883@google.com>
Hi Jonathan,
On Fri, 3 Jan 2020, Jonathan Nieder wrote:
Show 35 quoted lines
> Johannes Schindelin wrote: > > > As mentioned above, the idea is to prevent Git from attempting to create > > files with illegal file name characters. > [...] > > On Thu, 26 Dec 2019, Jonathan Nieder wrote: > > >> Is there anything we can or should do to prevent people checking in > >> new examples of paths with backslash in them (on all platforms)? > > > > As mentioned in my reply to Junio, I don't think that it would be wise to > > even try to warn about backslashes in the file names. There are _so_ many > > Git users out there, I am convinced that at least some of them have valid > > use cases for file names with backslashes in them. > > Thanks for the quick answers. It helps. > > I think allowing people to clone > https://github.com/zephyrproject-rtos/civetweb but not to check out > the problematic historic revision is a reasonable choice, especially > since it's still possible to get the data from there using > > git checkout <rev> -- . ':!bad-paths' > > [...] > > Or maybe you know of a code path in the `unpack_trees()` machinery that > > does _not_ go through `add_index_entry()`? I would be very interested to > > learn about such code paths. > > Every once in a while someone (e.g., in #git) has wanted "git checkout > --skip-index <rev> -- <paths>", and that would be the natural way to > implement such a thing. But no one has done it yet. :) > > We'll just have to keep a watchful eye as people make new > contributions.
Right.
As to my patch, in the meantime I wondered whether I should simply extend `verify_path()` to take a `flags` parameter where I can specify whether this is intended for checkout, and handle the backslashes _there_. That would cover e.g. uses of `make_transient_cache_entry()`, too.
The only reason why I would want to introduce `flags` is that `git apply` has this `--unsafe-paths` option where `verify_paths()` is called on the file names in the diff, and I was unsure whether there are legitimate use cases with diffs containing DOS-style paths (I suspect that there are legitimate scenarios where this is desirable).
What do you think of that?
Ciao, Dscho