Re: [PATCH 2/2] completion: suppress unwanted unescaping of `read`

From: Koichi Murase <myoga.murase@gmail.com>
Date: Apr 20, 2023, 22:31 UTC
Message-ID: <CAFLRLk9aLXx-j=W++qqiu5-Z0TpqdnyfR35+QA5aMZM=YRZvGQ@mail.gmail.com>
In-Reply-To: <xmqqmt321ozz.fsf@gitster.g>

Thank you for your review. The same as the other patch, this is also a change submitted to our project and then forwarded here.

2023年4月21日(金) 1:45 Junio C Hamano <gitster@pobox.com>:

Show 6 quoted lines

> [...] But I didn't validate
> the other claim "may contain backslash"---the "... file paths, which
> may contain ..." in the above example is a totally made up claim, as
> I do not have access to a platform whose pathname separator is
> backslash.  Please replace that part to describe the real world
> problem you encountered that led to this fix, if there is one.

Because of the background of this patch (which was originally submitted as a part of the consistent coding style in our project), I wouldn't think this change is associated with a problem that has happened in real use cases. But maybe Edwin has experienced actual problems.

Edwin, did you have actual problems with the current implementation of `__git_eread`?

For the record, I now installed Git for Windows in my Windows and created a repository, but .git/HEAD contains something like "ref: refs/heads/master" as usual.

Anyway, the default behavior of `read` without `-r` processing backslashes is just a historical one, and it is generally considered the best practice to always use `read -r` unless one intensionally unescapes backslashes. Using `read` without `-r` is exceptional, and doing so for no reason would be noisy in reading the code as the intent is unclear. If flag -r in `__git_eread` would be rejected, I would suggest adding code comments in `__git_eread` like "# We intensionally process backslashes in the file because XXX".

I'll soon submit a new patch with an updated commit message in the next reply.