Re: git rebase -i error message interprets \t in commit message
From: Junio C Hamano <hidden>
Date: 2016-06-15 22:58:20
Possibly related (same subject, not in this thread)
- 2016-06-15 · git rebase -i error message interprets \t in commit message · David Kastrup <hidden>
- 2016-06-15 · Re: git rebase -i error message interprets \t in commit message · Ramkumar Ramachandra <hidden>
- 2016-06-15 · Re: git rebase -i error message interprets \t in commit message · Matthieu Moy <hidden>
- 2016-06-15 · Re: git rebase -i error message interprets \t in commit message · David Kastrup <hidden>
- 2016-06-15 · Re: git rebase -i error message interprets \t in commit message · Matthieu Moy <hidden>
Matthieu Moy [off-list ref] writes:
quoted hunk
David Kastrup [off-list ref] writes:quoted
Could not apply 16de9d2... Make tempo range empo 20~30 be input as empo 20-30 insteadIndeed. The source of the problem is that our "die" shell function interprets \t (because it uses "echo"). A simple fix would be this:diff --git a/git-sh-setup.sh b/git-sh-setup.sh index 7a964ad..97258d5 100644 --- a/git-sh-setup.sh +++ b/git-sh-setup.sh@@ -53,7 +53,7 @@ die () { die_with_status () { status=$1 shift - echo >&2 "$*" + printf >&2 "%s\n" "$*" exit "$status" }It does not sound crazy as the shell function "say" right below uses the same printf "%s\n" "$*", but I'm wondering whether this could have other bad implications (e.g. if there are escape sequences in the commit message, aren't we going to screw up the terminal?).
I gave a quick look at "git grep -e 'die ' -- \*.sh" output, and I do not think this change will break things (i.e. no caller expects the non-portable behaviour of the shell such as "\c" at the end to omit the trailing newline). Thanks, care to roll it into a patch with a test or two?