Setting up a Custom Command for automating "amend non-last commit"

[jamesford42]

It looked like people have done this for the commit --fixup part already and that also works for me, but the next step would also be nice to automate if possible.

This next part: Stash. r-click new fixup commit > interactive rebase > squash into parent. confirm in resulting popup. unstash other changes.

I am not certain of the -exact- git commands Fork is using for the "interactive rebase into parent" and my own attempts also had an unavoidable editor popup (which corresponds i assume to the fork dialog popup after choosing 'squash into parent') -- ideally all that, and also --autostash would occur at the moment i have elected to perform the 'amend old commit' custom command.

[DanPristupov]

The part of this i don't really get is the exact git commands that Fork is using for the "interactive rebase into parent"

It's quite complicated.

Fork starts git rebase -i <sha>, passes an IPC-controllable text-editor which reads and parses the todo-list in the .git/rebase-apply directory, then replaces it with the new commands and asks git to proceed. Then it can be called again multiple times when a conflict occurs or an empty commit is encountered.

my own attempts also had an unavoidable editor popup

This is the process which is supposed to edit the given todo list and, when finished, return the zero exit code. It can be configured using sequence.editor config value.

[jamesford42]

Actually maybe im overcomplicating this. I could just.. stash changes, checkout the old commit, stash pop, stage and commit amend, stash changes, checkout head, stash pop.

Ehh, actually then I have to potentially deal with the same exact conflicts every time, for unrelated changes in my stash.

Better workflow might be: just leave the fixup commits there in the list, even multiples if i need to, adding stuff into the same previous commit. When i am actually done with putting all local changes where they need to be, I do an interactive rebase of it all then - and do the squashing of them etc.

[DanPristupov]

just leave the fixup commits there in the list, even multiples if i need to, adding stuff into the same previous commit. When i am actually done with putting all local changes where they need to be, I do an interactive rebase of it all then - and do the squashing of them etc.

That's what I do myself. Just make temporary commits with descriptive messages and them fixup them into corresponding commits.

[Otiel]

I have 3 custom commands for that:

• One when I have only one fixup commit to make:
  • Stage the changes I want to add in the commit
  • On the commit I want to fixup, call the following custom command:

    {
    "action" : {
    "script" : "git commit --fixup ${sha}\ngit -c sequence.editor=: rebase --interactive --autosquash --autostash ${sha}~1",
    "showOutput" : false,
    "type" : "sh",
    "waitForExit" : true
    },
    "name" : "Fixup Staged Files In Commit and Rebase Interactively (Autosquash) to Parent",
    "target" : "revision"
    }

  • And that's all. Staged changes are fixupped in the commit and the branch is rebased. No dialog popup (unless there are conflicts to solve of course).
• Two when I have more than one fixup commit to make:
  • Stage the changes I want to add in the commit
  • On the commit I want to fixup, call the following custom command:

    {
    "action" : {
    "args" : "commit --fixup ${sha}",
    "path" : "$git",
    "showOutput" : false,
    "type" : "process",
    "waitForExit" : true
    },
    "name" : "Fixup Staged Files In Commit",
    "target" : "revision"
    }

  • Repeat
  • Once I have created all my fixup commits, call the following custom command on the parent of the older commit I want to fixup:

    {
    "action" : {
    "args" : "-c sequence.editor=: rebase --interactive --autosquash --autostash ${sha}",
    "path" : "$git",
    "showOutput" : false,
    "type" : "process",
    "waitForExit" : true
    },
    "name" : "Rebase Interactively (Autosquash) to Here",
    "target" : "revision"
    }

[jamesford42]

Nice! I'll give those a try. Particularly the first one, when I want it done and out of the way. But, when multiple fixups have been committed, I'm starting to think that going through the interactive rebase popup (within fork) is probably not a bad thing, for the chance to decide between squash/fixup/etc, and a chance to review one more time. Though, it does seem to default to 'pick' action(s) for everything, when that doesn't really make sense for fixup commits.

[jamesford42]

Just wanted to close up this by saying that I am making loving and frequent use of the 'fixup commit' custom action which is literally just a regular git commit with --fixup.

Generally I build up several of these by the time im done doing whatever it is, usually either deconstructing a commit by feature, or just correcting stuff before its pushed, and then do an interactive rebase at the end -- and doing so once then does not seem so tedious but rather a necessary thing that requires my input to resolve conflicts, and quite frequently therefore could not be automated in a single custom action.

Here is my custom action for reference to others: Note that the lines starting with '#' are where i have commented them out, after finding it problematic when conflicts happen to have the rebase -i within a custom command.