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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]