Hi Junio,
On Sun, 25 Oct 2015, Junio C Hamano wrote:
> Johannes Schindelin <johannes.schinde...@gmx.de> 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"?
You mean mixed line endings? At least with this Windows 10 WordPad, *all*
line endings are normalized to CR/LF. That is, if you edit a file that
contains a stray CR, it is presented as a line break.
> * Is your shell ported correctly to the platform?
I would think so. It is an MSys2 program, therefore it uses all the POSIX
niceties, of course.
A simple test with CR/LF line endings in a script reveals that it is
pretty solid:
x=a
case "$x" in a) echo b;; esac
prints out 'b', as expected.
Please also note that things apparently worked alright before the patch
removing the stripspace call was applied.
> 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.
Please note that it is a bit unsettling if you use funny language like
"smells" here and then accuse me of not having an argument when I point
that the same rationale applies to having CR in IFS as applies to having
LF in IFS. Yes, that was an implicit argument, but it is a strong one, so
I do not think you are well served ignoring it.
> 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.
Again. If CR has no place in IFS, why does LF have a place in IFS? It
makes *no* sense to argue for one and against the other.
In any case, I am not interested in arguing for arguing's sake. Tell me
what you want instead of the patch to IFS, I will implement it and test
whether it fixes the bug and we will move on.
Ciao,
Johannes
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
