Re: [RFC,PATCH] git-amend -- darcs like amend-record for git

From: Kirill Smelkov <kirr@mns.spb.ru>
Date: Mar 3, 2010, 08:01 UTC
Message-ID: <20100303080114.GB2919@tugrik.mns.mnsspb.ru>
In-Reply-To: <20100301170859.GA4142@cthulhu>

On Mon, Mar 01, 2010 at 05:16:24PM +0800, Tay Ray Chuan wrote:

Show 15 quoted lines

> Hi,
> 
> On Thu, Feb 25, 2010 at 10:16 PM, Kirill Smelkov <kirr@mns.spb.ru> wrote:
> > Ever wanted to type `git commit --amend HEAD~3` ? But had to fall back to commit
> > and interactive rebase with fixup? And was tired by a lot of typing? And also
> > rebase works only on clean worktree, so stash save and stash pop have to be
> > used...
> >
> > Forget it.
> >
> > Now one can just do `git add ...` to prepare index, and then
> > `git amend <commit>` to merge that changes from index into <commit>.
> 
> this may be a little late, but I'd like to indicate my interest in
> such a feature.

On Mon, Mar 01, 2010 at 12:08:59PM -0500, Larry D'Anna wrote:

> I like it too.

Tay Ray, Larry, thanks for the feedback.

Now since it's obvious that at least some people need it too, I'll try to polish it. In the meantime, latest version is always available at

    git://repo.or.cz/git/kirr.git   q/git-amend

But I'm short on spare time, so don't expect something fast...

> A suggestion: I believe this could be better advertised as git-rebase
> --interactive --edit. After all, you do replay the intervening commits
> (which is closer to git-rebase than git-commit).

Thanks.

Yes, I do replay commits, but is it really a rebase? And also as to --edit thing - amending commits description is very handy, but is really just a nice artifact :).

What I think is really important (in at least my workflow) is to prepare changes in index, and then _merge_ them back to HEAD~2, i.e. not the latest commit.

I don't need this often, but sometimes I do, and in such cases `git amend` is right tool for the job.

That's why I still think git-amend is maybe a better name.

Though, I've found I'm now less reluctant to improving commit descriptions as well, and exactly because of that nice --edit artifact behaviour :)

As to the merging, the only a bit unclear moment to me, is to how properly handle merge conflicts, when propagating index back to HEAD~2.

Kirill