Re: git-rebase dirty index and email address bug?

From: Jeff King <peff@peff.net>
Date: Mar 2, 2008, 07:26 UTC
Message-ID: <20080302072622.GB3935@coredump.intra.peff.net>
In-Reply-To: <slrnfsjfpo.3fl.jgoerzen@katherina.lan.complete.org>

On Sat, Mar 01, 2008 at 02:40:24PM -0600, John Goerzen wrote:

Show 7 quoted lines

> odd.  Today I git fetched the remote, and then I tried to git rebase
> upstream/master.  I had committed all outstanding changes first.  My
> index was clean.  It displayed:
> 
> First, rewinding head to replay your work on top of it...
> HEAD is now at 77f1a60... Merge branch 'trunk'
> Dirty index: cannot apply patches (dirty: public/dispatch.fcgi)

That seems quite strange, since git-rebase did a "git-reset --hard", which should have cleared your index anyway. And then it runs "git format-patch | git am", and "am" is responsible for the "Dirty index" message. So perhaps there is something in your commit that is triggering a bug when piped in this way.

I tried cloning the "mainline.git" repository you mentioned and doing a few simple tests, but was unable to reproduce. Can you make available the commits that you are trying to rebase?

Show 8 quoted lines

> So I tried the git reset command on public/dispatch.fcgi, and also
> then deleted that file.  I then tried git-rebase --continue, which
> displayed:
> 
> sed: can't read .dotest/info: No such file or directory
> sed: can't read .dotest/info: No such file or directory
> sed: can't read .dotest/info: No such file or directory
> Patch does not have a valid e-mail address.

Hrm. I don't think it has anything to do with your email address being invalid, but rather that we somehow failed to create the 'info' file containing information about the commit.

Show 10 quoted lines

> converted from an svn repo using, presumably, git-svn or
> git-svnimport.  It lies at
> git://gitorious.org/redmine-git/mainline.git
> 
> Most patches have an author like this:
> 
> Author: jplang <jplang@e93f8b46-1217-0410-a6f0-8f06a7374b81>
> 
> Could one of the git tools be trying to parse this for some odd
> reason?

No, that should parse fine. I think there is something more fundamental going wrong.

-Peff