# rebase failure if commit message looks like a patch

2 messages from 2009-01-27 to 2009-01-27. Participants: Anton, Johannes Schindelin.
Thread: https://gitlist.dev/t/17396

## Anton, 2009-01-27 17:50

Subject: rebase failure if commit message looks like a patch
Message-ID: <loom.20090127T173025-125@post.gmane.org>
URL: https://gitlist.dev/e/loom.20090127T173025-125%40post.gmane.org

```
I have found a strange behaviour of "git rebase", present in following versions:

git 1.6.1, linux,
git 1.6.0.4, cygwin

if the commit message of one of revisions on local branch
containing something, what looks like patch:

------------------ bad-commit-message { ---------------
changeset a1 - feature added

--- a0  2009-01-25 10:09:05.953125000 +0100
+++ ./r/a       2009-01-25 10:15:20.093750000 +0100
@@ -1,5 +1,5 @@
-1
+1 - upstream
 2
 3
 4
-5
+5 - feature
------------------ bad-commit-message } ---------------

Following shell script reproduces the bug for me:

------------------ show-bug.sh { ---------------
#!/bin/bash
rm -rf r # clean-up
mkdir r # repo dir
cd r
git init
cd ..
cp a0 r/a
cd r
git add a
git ci -m "initial addition of a0"
git br feature
git co feature
cd ..
cp a1 r/a
cd r
git add a
## no bug
#git ci -m "changeset a1 - feature added"
# bug
git ci -F ../bad-commit-message
git co master
cd ..
cp a2 r/a
cd r
git add a
git ci -m "changeset a2 - upstream revision"
git co feature
git rebase master
------------------ show-bug.sh } ---------------

produces the error on final rebase attempt:

First, rewinding head to replay your work on top of it...
Applying: changeset a1 - feature added
error: r/a: does not exist in index
fatal: sha1 information is lacking or useless (r/a).
Repository lacks necessary blobs to fall back on 3-way merge.
Cannot fall back to three-way merge.
Patch failed at 0001.

When you have resolved this problem run "git rebase --continue".
If you would prefer to skip this patch, instead run "git rebase --skip".
To restore the original branch and stop rebasing run "git rebase --abort".

In case one uses
# no bug
git ci -m "changeset a1 - feature added"
instead of
# bug
git ci -F ../bad-commit-message

The final rebase succeded !

Content of other files:

---------------- a0 { -------------------
1
2
3
4
5
---------------- a0 } -------------------

---------------- a1 { -------------------
1
2
3
4
5 - feature
---------------- a1 } -------------------

---------------- a2 { -------------------
1 - upstream
2
3
4
5
---------------- a2 } -------------------

-- 
Anton

```

## Johannes Schindelin, 2009-01-27 18:15

Subject: Re: rebase failure if commit message looks like a patch
Message-ID: <alpine.DEB.1.00.0901271914130.3586@pacific.mpi-cbg.de>
URL: https://gitlist.dev/e/alpine.DEB.1.00.0901271914130.3586%40pacific.mpi-cbg.de
In-Reply-To: <loom.20090127T173025-125@post.gmane.org>

```
Hi,

On Tue, 27 Jan 2009, Anton wrote:

> I have found a strange behaviour of "git rebase", present in following 
> versions:

That is a known issue.  Please work around it with redoing the rebase with 
-m.

I could imagine that we should scan the commit messages before actually 
running rebase, and either activate -m, or escape the "diff" with a 
backslash (as is frequently done with "From" in mails).

Ciao,
Dscho

```