Re: Bug: git-rebase goofs up \n in commit messages

Jeff King [off-list ref] writes:

On Fri, May 25, 2007 at 09:59:43PM -0700, Junio C Hamano wrote:

quoted

 * I suspect we would declare either "war on echo" or "harder push
   for builtins" triggered by these.

Cry havoc! More fixes below (just a diff -- maybe we want to aggregate
these into a single commit?).

These are the ones I noticed that use commit messages (which are
probably the most likely to use backslash). There are _tons_ of uses for
heads and filenames. I think we either should stop with commit messages,
or go all-out and simply remove all uses of echo (because there are
literally hundreds otherwise).

At least the ones you did look very sane to me.  Will apply with
appropriate log message, credit to you.

Thanks.

I do not think we need to do all the uses of 'echo'.  Many of
them are clearly fixed string we know about, object names we
parsed out of plumbing output, refnames and refspecs, all of
which should be safe.

Other worrisome ones are pathnames, but (1) I do not think
anybody is insane enough to have slashed funnies in their
pathname components, (2) half the pathnames we deal with come
from plumbing output which use '/' as path component separator
even on Windows, (3) users can use forward slash as path
component separator in their input even on Windows, and (4) even
though we try to use -z output from plumbing and read it with -0
capable downstream in some of our pipelines, many pure-shell
scripts read non-z output using shell built-in "read" and do not
unquote c-quoted ones, so they do not work correctly if you have
HT or LF in your pathnames anyway (notable exception is that
pipelines between git plumbing, e.g. "ls-files | update-index
--stdin", are safe without -z, as the downstream knows how to
unquote c-quoted paths).

I would expect that by the time we run out of more important
things to worry about and start worrying about truly funny
pathnames, we would have rewritten more of the remaining
Porcelains shell scripts in C, which automatically would make
this problem go away.