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@xxxxxxxxx>: > [...] 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.
