On Jul 27, 4:48 pm, misha680 <misha...@gmail.com> wrote:
> > > I have heard great things about this 
> > > list:http://kerneltrap.org/mailarchive/git/2008/6/4/2025514
> > > I love git rebase --interactive, but would like to have the same
> > > functionality for editing the actual diffs themselves (e.g., two
> > > commits back).
> > Not sure if this is what you wanted:
> >  * git rebase -i some_old_commit
> >  * Change 'pick' to 'edit' for commits that you're interested in
> >  * When git rebase pauses for you to edit commit, do 'git reset'
> > leaving your files unstaged
> >  * Then invoke 'git add -e', and you should be able to edit your
> > patch.
> That almost seems to do the trick.
> However, it seems when I do git reset I get an empty commit.
> If I do something like:
> git reset HEAD^
> my commit becomes non-empty, but then I am obviously on a different
> commit when I do
> git commit --amend
> Any hints? I am guessing there might be an extra parameter or smthng
> to git reset.

Just omit "--amend" when committing.

Explanation: if you specify "edit" action for a commit when rebasing,
Git *performs* that commit and then drops you back to the shell so
that you could amend it, that is, you already have that commit at the
HEAD and then you can make some changes and amend it (replace with a
new commit) or just continue rebasing (effectively turning "edit" to

But if you do `git reset HEAD^` at that point, this means "forget the
commit at the HEAD and reposition the HEAD to point to its parent
commit", so when you then make some changes and commit them, you
really mean creating a new commit, not amending the old one because it
does not exist anymore (you rewound the HEAD to point to its parent).

You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To post to this group, send email to git-us...@googlegroups.com.
To unsubscribe from this group, send email to 
For more options, visit this group at 

Reply via email to