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

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

[Kirill Smelkov]

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>.

Yes, it uses rebase behind the scenes (or better sequencer, when it is
available), but the end result is less typing and much better usability for
humans. And it even tries to work in dirty worktree...

So operations like amending HEAD~3 take not significanltly more time, than
just amending HEAD with already available `git commit --amend`.

It's only a prototype, without documentation and tests, just an RFC.

If you find the idea useful, please let me know. In case people want something
like this, I'll try to polish it for inclusion into git.

Thanks,
Kirill
---
 contrib/git-amend.sh |   53 ++++++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 53 insertions(+), 0 deletions(-)
 create mode 100755 contrib/git-amend.sh

diff --git a/contrib/git-amend.sh b/contrib/git-amend.sh
new file mode 100755
index 0000000..1778594
--- /dev/null
+++ b/contrib/git-amend.sh
@@ -0,0 +1,53 @@
+#!/bin/sh -e
+# git-amend: darcs like amend-record for git
+# FIXME error handling
+
+USAGE="<commit>"
+. git-sh-setup
+
+test "$#" = 1 || usage
+
+commit=$1
+
+# let's see if $commit is a valid one, and also transform it to sha1 for it not
+# to be dependant on current HEAD
+commit=$(git rev-parse "$commit")
+
+# look out merges!
+test -z "$(git log --merges ${commit}~..HEAD)" || \
+	die "E: can't amend commits behind merges"
+
+# commit index, allowing empty commit just for being able to amend patch
+# description
+git commit --allow-empty -m "amend for $commit"
+
+# save worktree/index state
+work=$(git stash create)
+test -n "$work" && git update-ref HEAD.amend-backup $work
+
+# reset to clean work/index before going into rebase
+git reset --hard HEAD
+
+fixup_cmd=$(mktemp -t git-amend-fixupcmd.XXXXXX)
+rest_cmd=$(mktemp -t git-amend-restcmd.XXXXXX)
+trap 'rm -f "$fixup_cmd" "$rest_cmd"' 0
+{
+echo -ne "pick\t";  git log --pretty=oneline -1 ${commit}
+echo -ne "fixup\t"; git log --pretty=oneline -1 ${HEAD}
+} > "$fixup_cmd"
+
+git log --pretty=oneline --reverse ${commit}..HEAD~ | awk '{print "pick\t" $0;}' \
+	> "$rest_cmd"
+
+# now let's apply fixup part to commit
+GIT_EDITOR="cat $fixup_cmd >" git rebase -i ${commit}~
+
+# reword it
+git commit -v --amend
+
+# and apply rest
+GIT_EDITOR="cat $rest_cmd >" git rebase -i HEAD
+
+
+# restore worktree/index state
+test -n "$work" && git stash apply --index $work
-- 
1.7.0.91.g9803

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

[Tay Ray Chuan]

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.

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).

-- 
Cheers,
Ray Chuan

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

[Larry D'Anna]

* Tay Ray Chuan (rctay89@gmail.com) [100301 04:16]:
> 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.

I like it too.

  --larry

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

[Kirill Smelkov]

On Mon, Mar 01, 2010 at 05:16:24PM +0800, Tay Ray Chuan wrote:
> 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