Re: [PATCH v2] rebase -i: respect core.commentchar
From: Junio C Hamano <hidden>
Date: 2016-06-15 22:56:08
Possibly related (same subject, not in this thread)
- 2016-06-15 · Re: [PATCH v2] rebase -i: respect core.commentchar · Junio C Hamano <hidden>
- 2016-06-15 · Re: [PATCH v2] rebase -i: respect core.commentchar · John Keeping <hidden>
- 2016-06-15 · Re: [PATCH v2] rebase -i: respect core.commentchar · Junio C Hamano <hidden>
- 2016-06-15 · Re: [PATCH v2] rebase -i: respect core.commentchar · John Keeping <hidden>
- 2016-06-15 · Re: [PATCH v2] rebase -i: respect core.commentchar · Junio C Hamano <hidden>
John Keeping [off-list ref] writes:
quoted hunk ↗ jump to hunk
@@ -179,7 +182,9 @@ die_abort () { } has_action () { - sane_grep '^[^#]' "$1" >/dev/null + echo "space stripped actions:" >&2 + git stripspace --strip-comments <"$1" >&2 + test -n "$(git stripspace --strip-comments <"$1")" }
I'll remove the debugging remnants while queuing.
fixup) echo - echo "# The $(nth_string $count) commit message will be skipped:" + printf '%s\n' "$comment_char The $(nth_string $count) commit message will be skipped:" echo - commit_message $2 | sed -e 's/^/# /' + # Change the space after the comment character to TAB: + commit_message $2 | git stripspace --comment-lines | sed -e 's/ / /'
I think this changes the behaviour but in a good way. It used to show an empty line in the incoming commit message to a hash followed by a trailing HT before the end of line, but now it only emits the comment char immediately followed by the end of line.
quoted hunk ↗ jump to hunk
@@ -942,20 +948,18 @@ test -s "$todo" || echo noop >> "$todo" test -n "$autosquash" && rearrange_squash "$todo" test -n "$cmd" && add_exec_commands "$todo" -cat >> "$todo" << EOF - -# Rebase $shortrevisions onto $shortonto -EOF +echo >>"$todo" +printf '%s\n' "$comment_char Rebase $shortrevisions onto $shortonto" >>"$todo"
I think you can still do cat >>"$todo" <<EOF $comment_char Rebase $shortrevisions onto... EOF here with any funny comment character. Doing this with two separate I/O does not hurt very much, but the resulting code may be easier to scan if left as here-text with a single cat. Please eyeball what is in 'pu' (I have a separate squashable fixup on top of your patch) and let me know if I made mistakes. Thanks for working on this.