On Tue, Nov 29, 2016 at 10:42:18AM -0800, Junio C Hamano wrote:
> tbo...@web.de writes:
>
> > From: Torsten Bögershausen <tbo...@web.de>
> >
> > Working with a repo that used to be all CRLF. At some point it
> > was changed to all LF, with `text=auto` in .gitattributes.
> > Trying to cherry-pick a commit from before the switchover fails:
> >
> > $ git cherry-pick -Xrenormalize <commit>
> > fatal: CRLF would be replaced by LF in [path]
>
> OK. That's a very clear description of the symptom that can be
> observed from the surface.
>
> > Whenever crlf_action is CRLF_TEXT_XXX and not CRLF_AUTO_XXX,
> > SAFE_CRLF_RENORMALIZE must be turned into CRLF_SAFE_FALSE.
>
> Aside from needing s/CRLF_SAFE/SAFE_CRLF/, this however lacks
> "Otherwise, because of X and Y, Z ends up doing W" to explain
> the "must be" part. Care to explain it a bit more?
Thanks for the review - how about this:
convert: git cherry-pick -Xrenormalize did not work
Working with a repo that used to be all CRLF. At some point it
was changed to all LF, with `text=auto` in .gitattributes.
Trying to cherry-pick a commit from before the switchover fails:
$ git cherry-pick -Xrenormalize <commit>
fatal: CRLF would be replaced by LF in [path]
Commit 65237284 "unify the "auto" handling of CRLF" introduced
a regression:
Whenever crlf_action is CRLF_TEXT_XXX and not CRLF_AUTO_XXX,
SAFE_CRLF_RENORMALIZE was feed into check_safe_crlf().
This is wrong because here everything else than SAFE_CRLF_WARN is
treated as SAFE_CRLF_FAIL.
Solution: Turn SAFE_CRLF_RENORMALIZE into SAFE_CRLF_FALSE before
calling check_safe_crlf().
Reported-by: Eevee (Lexy Munroe) <ee...@veekun.com>
Signed-off-by: Torsten Bögershausen <tbo...@web.de>
