Subject: Re: [PATCH v2 0/2] Fix interactive rebase when the editor saves with CR/LF

From: Junio C Hamano <[email-masked]>
Date: Sun, 25 Oct 2015 12:12:56 -0700

Johannes Schindelin <[email-masked]> writes:

> Chad Boles reported that `git rebase -i` recently started producing
> errors when the editor saves files with DOS line endings. The symptom
> is:
>
> 	Warning: the command isn't recognized in the following line:
> 	 -
>
> 	You can fix this with 'git rebase --edit-todo'.
> 	Or you can abort the rebase with 'git rebase --abort'.
>
> The real bummer is that simply calling `git rebase --continue` "fixes"
> it.

Two questions.

 * What does the DOS editor do to a file with ^M in the middle of a
   line, e.g. "A^MB^M^J"?

 * Is your shell ported correctly to the platform?

The latter may need a bit of elaboration.  "read a b c" is supposed
to read one line of text (where the definition of line is platform
dependent, your platform may use CRLF to signal the end of an line),
split the characters on the line (i.e. LF vs CRLF no longer matters
at this point) at $IFS characters and give them to $a $b and $c. If
the platform accepts CRLF as the EOL signal, should the program still
see CR at the end of $c?

A solution that mucks with IFS smells like fixing a wrong problem
without addressing the real cause.

Also IFS is used not only by "read", so munging it globally doubly
feels wrong.

In addition, you do not want to split at CR; what you want is to
treat CRLF (i.e. not a lone CR) as the end-of-line separator.
Adding CR to IFS feels triply wrong.

By the way, saying "This is right, really" makes you sound as if you
do not have a real argument.