[PATCH 10/11] completion: improve handling quoted paths in 'git ls-files's output

If any pathname contains backslash, double quote, tab, newline, or any control characters, 'git ls-files' and 'git diff-index' will enclose that pathname in double quotes and escape those special characters using C-style one-character escape sequences or \nnn octal values. This prevents those

[PATCH 05/11] completion: improve handling quoted paths on the command line

Our git-aware path completion doesn't work when it has to complete a word already containing quoted and/or backslash-escaped characters on the command line. The root cause of the issue is that completion functions see all words on the command line verbatim, i.e. including all backslash, single

Re: Handling of paths

On Fri, Jul 21, 2017 at 08:15:17AM -0700, Junio C Hamano wrote: > In general, I (and other experienced reviewers here) prefer to give > chances to people who are new to the Git development community and > are inclined to do so to scratch their own itch, by giving analysis > of the problem and a

Re: Handling of paths

Victor Toni writes: > 2017-07-20 22:30 GMT+02:00 Junio C Hamano : >> >> I've read the function again and I think the attached patch covers >> everything that ought to be a filename. >> > Your swift reaction is very much appreciated. > With the background

Re: Handling of paths

2017-07-20 22:30 GMT+02:00 Junio C Hamano : > > I've read the function again and I think the attached patch covers > everything that ought to be a filename. > Your swift reaction is very much appreciated. With the background you gave I just started to to create a patch myself

Re: Handling of paths

On Thu, Jul 20, 2017 at 01:30:52PM -0700, Junio C Hamano wrote: > > I've read the function again and I think the attached patch covers > everything that ought to be a filename. > > By the way, to credit you, do you prefer your bloomberg or hashpling > address? The patch looks good to me. It's

Re: Handling of paths

Charles Bailey writes: > On Thu, Jul 20, 2017 at 12:42:40PM -0700, Junio C Hamano wrote: >> Victor Toni writes: >> >> > What's unexpected is that paths used for sslKey or sslCert are treated >> > differently insofar as they are expected to be

Re: Handling of paths

On Thu, Jul 20, 2017 at 12:42:40PM -0700, Junio C Hamano wrote: > Victor Toni writes: > > > What's unexpected is that paths used for sslKey or sslCert are treated > > differently insofar as they are expected to be absolute. > > Relative paths (whether with or without "~")

Re: Handling of paths

Victor Toni writes: > What's unexpected is that paths used for sslKey or sslCert are treated > differently insofar as they are expected to be absolute. > Relative paths (whether with or without "~") don't work. Looking at http.c::http_options(), I see that "sslcapath" and

Handling of paths

Hello, I have a .gitconfig in which I try to separate work and private stuff by using includes which works great. When using [include] the path is treated either - relative to the including file (if the path itself relative) - relative to the home directory if it starts with ~ - absolute if the

Re: [PATCH 0/2] handling alternates paths with colons

On Tue, Dec 13, 2016 at 10:42:39AM -0800, Junio C Hamano wrote: > Jeff King writes: > > > Right, but we also support relative paths via environment variables. I > > don't think that changes the conclusion though. I'm not convinced > > relative paths via the environment aren't

Re: [PATCH 0/2] handling alternates paths with colons

Jeff King writes: > Right, but we also support relative paths via environment variables. I > don't think that changes the conclusion though. I'm not convinced > relative paths via the environment aren't slightly insane in the first > place, Sorry, a triple negation is above my

Re: [PATCH 0/2] handling alternates paths with colons

On Tue, Dec 13, 2016 at 10:10:54AM -0800, Junio C Hamano wrote: > > We do support non-absolute paths, both in alternates files and > > environment variables. It's a nice feature if you want to have a > > relocatable family of shared repositories. I'd imagine that most cases > > start with "../",

Re: [PATCH 0/2] handling alternates paths with colons

Jeff King writes: > On Mon, Dec 12, 2016 at 02:37:08PM -0800, Junio C Hamano wrote: > >> Jeff King writes: >> >> > So here are patches that do that. It kicks in only when the first >> > character of a path is a double-quote, and then expects the usual >> > C-style

Re: [PATCH 0/2] handling alternates paths with colons

On Mon, Dec 12, 2016 at 02:37:08PM -0800, Junio C Hamano wrote: > Jeff King writes: > > > So here are patches that do that. It kicks in only when the first > > character of a path is a double-quote, and then expects the usual > > C-style quoting. > > The quote being per

Re: [PATCH 0/2] handling alternates paths with colons

Jeff King writes: > So here are patches that do that. It kicks in only when the first > character of a path is a double-quote, and then expects the usual > C-style quoting. The quote being per delimited component is what makes this fifth approach a huge win. All sane

[PATCH 0/2] handling alternates paths with colons

On Sat, Dec 10, 2016 at 03:51:33AM -0500, Jeff King wrote: > So here's the array of options, as I see it: > > 1. Disable quarantine by default; only turn it on if you don't have > any of the funny corner cases. > > 2. Introduce an extra single-item environment variable that gets >

Re: [PATCH 14/22] lockfile: use strbufs when handling (most) paths

Michael Haggerty mhag...@alum.mit.edu writes: Change struct lock_file's filename field from a fixed-length buffer into a strbuf. Good. As I allued to in a review on an unrelated patch, I do not think it is a good idea to name the lock filename field lock_filename in a structure that is about

Re: [PATCH 14/22] lockfile: use strbufs when handling (most) paths

On Tue, Apr 01, 2014 at 05:58:22PM +0200, Michael Haggerty wrote: /* - * p = path that may be a symlink - * s = full size of p - * - * If p is a symlink, attempt to overwrite p with a path to the real - * file or directory (which may or may not exist), following a chain of - * symlinks if