On Jul 27, 10:40 pm, misha680 <misha...@gmail.com> wrote:
> On Jul 27, 9:11 am, Konstantin Khomoutov <khomou...@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
> > "pick").
> > 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).
> Wow thank you very much for the very clear explanation.
> I now understand that I should do:
> 1. git rebase -i commit
> 2. change commit from "pick" to "edit"
> 3. git reset HEAD^
> 4. git add -e
> 5. edit my patch
> 6. git commit -a -n
> 7. type in new (old) commit name
> 8. git rebase --continue
a) I see no reason to routinely use "-n" with git-commit. Looks over-
hackish for regular usage.
b) Same applies to "-a": if you created a file while editing your
commit (say, split a file into several pieces), it won't be added when
you do `git commit -a`.
c) I prefer to use "-p" or "--patch" with `git add`. It's a matter of
taste, really, but I advise you to look at it as it may appear to be
more convenient than "-e". Or not. ;-)
> Its too bad there's no way to keep the commit name.
Provided you did not move the HEAD after `git reset HEAD^`, just do
git commit -c ORIG_HEAD
to reuse the original commit message and get a chance to edit it or do
git commit -C ORIG_HEAD
to just use it and go ahead (you will not be dropped into your
Refer to git-rev-parse man page for more info on this.
In any case, you can record (copy and paste somewhere or whatever) the
name of the HEAD commit before zapping it and then use "-c" or "-C"
with that commit name when running `git commit`. This is because that
commit will not be evaporised completely during reset, just made
unreferenced from your tree.
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