[PATCH] git-rebase--interactive: Handle commit messages that end in backslash

This patch fixes three issues with handling commits that end in a
backslash character ("\"), two of which had potential for silent data
"loss".

First, if you had two commits

  abcde...   Remove trailing \
  01234...   Another commit

then git rebase -i formatted this in your editor like so:

 pick abcde Remove trailing pick 01234: Another commit

Assuming you don't spot this visually, git-rebase will then happily skip
over 01234 upon processing, removing that commit disappear from your HEAD
(!).

Secondly, when skipping over commits whose parents were unchanged, if any
of these commits ended in a backslash, it would try and ignore it.

Lastly, this patch fixes "edit"ing and "squash"ing of commits that end
in a backslash; git-rebase would previously blow up.

Signed-off-by: Chris Lamb <redacted>
---
 git-rebase--interactive.sh |    8 ++++----
 1 files changed, 4 insertions(+), 4 deletions(-)


Regards,

-- 
      ,''`.
     : :'  :     Chris Lamb
     `. `'`      lamby@debian.org
       `-

Chris Lamb wrote:
 

This patch fixes three issues with handling commits that end in a
backslash character ("\"), two of which had potential for silent data
"loss".

Disregard the patch; it has some funky side-effect which breaks ONTO
parsing and I don't know why.

(The problem still exists though.)


Regards,

-- 
      ,''`.
     : :'  :     Chris Lamb
     `. `'`      lamby@debian.org
       `-

On Thu, May 13, 2010 at 01:58:07PM +0100, Chris Lamb wrote:

Disregard the patch; it has some funky side-effect which breaks ONTO
parsing and I don't know why.

(The problem still exists though.)

Hmm. It looks like there is more weirdness, too. Try

  git commit -m 'magic \\n newline'

I get a stray newline in the git-rebase-todo file. IIRC, we had this
problem before because some shells' "echo" will interpret, and some will
not (I think bash will not, but dash will). So there are a few "echo"
calls that need to be "printf %s" in git-rebase--interactive.

But I wonder if we would do better to simply sanitize the subject line
of metacharacters. As I understand it[1], the subject line shown is for
human consumption only, and the actual operations happen on the included
sha1. So we could munge it in a non-reversible way without breaking
anything.

-Peff

[1] I may be wrong. This is not code I'm too familiar with, and I do
remember a proposal at some point for automagically handling subjects
with "wip" or "squash" in them. Still, a light munging may work.

Jeff King wrote:

As I understand it[1], the subject line shown is for
human consumption only, and the actual operations happen on the included
sha1. So we could munge it in a non-reversible way without breaking
anything.

-Peff

[1] I may be wrong. This is not code I'm too familiar with, and I do
remember a proposal at some point for automagically handling subjects
with "wip" or "squash" in them. Still, a light munging may work.

During the actual rebasing, only the 'cmd sha' portion of the line
matters, as evidenced by the code doing

  do_next () {
          rm -f "$MSG" "$AUTHOR_SCRIPT" "$AMEND" || exit
          read command sha1 rest < "$TODO"

and then not using $rest except in status messages.

The automatic handling you are referring to is --autosquash, which
happens in rearrange_squash() which is a preprocessing stage.  AFAICS
that function is still okay iff the munging maps prefixes to prefixes.

-- 
Thomas Rast
trast@{inf,student}.ethz.ch