Add amend - support amending any patch within the stack

[jameswalmsley]

[drewdeponte]

This is interesting. I didn't realize it was still a two step process.

1. create a fixup commit
2. run interactive rebase with --autosquash, which will then cause it to detect the commit summaries and the action! prefix and appropriately apply it in the todo list

[drewdeponte]

Seems however we could actually have the command.

1. create an index
2. cherry pick the stack, amending the patch identified by the patch index with the new index

Then it would be a one step process. What are your thoughts?

[jameswalmsley-cpi]

Seems however we could actually have the command.

1. create an index
2. cherry pick the stack, amending the patch identified by the patch index with the new index

Then it would be a one step process. What are your thoughts?

That's possible. However I like that the commands are relatively orthogonal.

With the current implementation, we have a low complexity implementation, which means I can make multiple changes to different patches and amend multiple patches before running a rebase.

Main reason I guess for that is to prevent "stash-then-rebase".

However if you can effective do the same, with low-overhead and no side-effects to the git state.. then that would be neat. (I.e. state after running this command is the same as before except for the amend).

I think as currently implemented you take the heavy lifting out of one of the most common scenarios.

[drewdeponte]

Just trying to make sure that I understand. My understanding with git commit --fixup is that it takes your staged changes and makes a commit with them that has a specially named summary that loosely associates it to the other commit that you specified.

You can create a number of different fixup commits that should address different patches lower in your stack.

Then after you have made these commits you have to run a git rebase -i --autosquash which tells rebase to look for these losely associated commits by git commit summary and reorder and mark them with the appropriate action in the todo.

So fundamentally I am running the following commands.

• git commit --fixup
• git rebase -i --autosquash

In the existing workflow there are a few approaches you can take to accomplish this.

One, you could use gps rebase and mark the patch you want to modify for edit and then make your changes and then do a git rebase --continue.

The other aproach would be to create the commit on top of the stack, naming it whatever is meaningful to you in its summary with just git commit. Then you rebase the stack with gps rebase, reorder the patches, and explicitly squash/fixup etc. one patch into the other.

So the commands are basically the same

• git commit
• gps rebase

The only difference I really see is the following two.

• the git commit --fixup command is slightly simplified as you don't have to use the short sha and instead can use the patch index from gps ls
• the reordering and action flagging in the interactive rebase is done for you based on the arguments you made to the git commit --fixup command before, rather than explictly ordering the patches and flagging them within the interactive rebase.

Neither of these by themselves are significant in terms of flow in my mind. In fact I actually prefer to just create the commits and then review, reorder, squash/fixup, etc. them in the interactive rebase explicitly.

Without doing more, like actually handling the cherry picking this feels very much like a proxy command still because the difference is relatively small.

The problem with these proxyish commands is that there are a million different variations based on everyones different preferences and workflows.

Maybe there is a way to solve proxy style things like this in a more generic way?

What if there was a gps sha <patch-index> command that would lookup the patch stack index and output the sha?

Then you could do things like git commit --fixup=amend:$(gps sha 4) or git commit --fixup=reword:$(gps sha 4) or git commit --squash=$(gps sha 4)?

[drewdeponte]

Was just thinking another possibly interesting idea of having the gps sha command like that is lets say you that you git commit --fixup=amend all the time in your personal workflow. Well you could use either shell alias or git aliases to create an alaias like, git a 4 that would map to git commit --fixup=amend:$(gps sha 4). Anyways, just more food for thought.

[jameswalmsley-cpi]

Was just thinking another possibly interesting idea of having the gps sha command like that is lets say you that you git commit --fixup=amend all the time in your personal workflow. Well you could use either shell alias or git aliases to create an alaias like, git a 4 that would map to git commit --fixup=amend:$(gps sha 4). Anyways, just more food for thought.

Like the idea of gps sha it would certainly make it possible to "extend" gps without actually needing to modify the core. I'm going to join you slack... hope to catch you there.

[drewdeponte]

@jameswalmsley, I have thought more about this and I think I have made up my mind.

I think we shouldn't do this as it is too much of a proxy function.

We can see this in that we are providing a specific limited subset of functionality of the git commit --fixup and not providing the related git commit --squash. Being in a position to have to maintain parity with Git itself on proxyish functionality is not a winning strategy.

I think a much better strategy going forward is to add a gps sha <patch-index> command that can be composed with in Git alias or shell aliases to create whatever personalized workflow you want with Git proper. Something like, git commit --fixup=amend:$(gps sha <patch index>) could be setup as an alias.

Therefore, I am closing this pull request.