Feature Request: Interactively pick fixup revision

Hi,

first email to this list, so please forgive me if I'm doing something wrong.

My usual workflow is using `git commit --fixup <revision>` quite frequently, as it eases the code reviewing process and allows for a clean history later on.

One thing that is always cumbersome is to first find the SHA of the revision that I plan to commit a fixup to. I usually use git log and then copy the revision. I even wrote a script that eases this process using fzf: ``` #!/bin/bash

res=$(git log --oneline | fzf) ref=$(echo $res | cut -d ' ' -f1)

git commit --fixup ${ref} ```

I don't think fzf is really necessary here, but it speeds things up.

Anyhow, I'm really surprised that this isn't a feature of git. I could see a `git commit --fixup` (without a revision) or `git commit --fixup --interactive` open up the git log and let one pick the revision they want to commit a fixup to.

Cheers, Martin

On November 9, 2024 6:41 AM, Martin Imre wrote:

You might find that git rebase --autosquash -i <commit> might do what you are looking for. This allows you to clean up your topic branch prior to creating a pull request. Loads of documentation online about its use.

Good luck, Randall

On Sat, Nov 9, 2context for all your replies. Please also see below.024 at 2:09 PM <rsbecker@nexbridge.com> wrote:

I think you might have misunderstood what I'm trying to achieve.

After adding a fixup commit, I'm anyway running `git rebase --autosquash -i <commit>`.

However, my request is to get an interactive way to pick _which_ commit a fixup is targeting. Ie, I'm trying to run something that pops up a pager with the commit log for me to pick a commit that is then passed to `git commit --fixup <commit>`.

If you have fzf, try running my script in a git repo with some changes and you'll see what I'm trying to achieve.

Cheers, Martin

On Sat Nov 9, 2024 at 12:41 PM CET, Martin Imre wrote:

https://github.com/keis/git-fixup/

but at least as a minimal improvement, I would limit list of commits to those which are touched in the staging area:

  ref=$(git log --oneline -- $(git diff --cached|lsdiff --strip 1)|fzf|cut -d ' ' -f1)

(lsdiff is from patchutils)

Best,

Matěj

On Sat, Nov 9, 2024, at 15:55, Matěj Cepl wrote:

This or git-absorb(1) (I have only tried the latter) is good if you want to fixup previously touched lines. That is likely to be the case for a fixup command. But maybe you for example want to add a test to some change which is in a different file. In which case you want to pick the commit manually.

I haven’t heard of lsdiff(1) though. That’s something I have been wanting lately. Thanks.

On Sat Nov 9, 2024 at 6:13 PM CET, Kristoffer Haugsbakk wrote:

https://github.com/twaugh/patchutils (part of any Linux distro) … it is absolutely indispensable set of tools for any developer, IMHO.

Matěj

Thanks for pointing me towards https://github.com/keis/git-fixup/ and git-absorb (https://github.com/tummychow/git-absorb). I'll try them out and see if I like the ergonomics of them.

Just as a general question: With 2 (or even more) different implementations that solve the same problem, wouldn't this be a good addition for a future version of git?

Also, out of curiosity, how do they achieve their binaries to be called as git commands, ie, why can I call the binary `git-fixup` via `git fixup`?

Cheers, Martin

On Sun, Nov 10, 2024, at 08:55, Martin Imre wrote:

They don’t do anything special. Any script or binary that you define yourself will be treated the same. `git` takes care of it.

On 10.11.24 08:55, Martin Imre wrote:

I'll throw a third one into the mix: lazygit. It's a TUI client that has similar functionality built in. (See [1])

As for why this isn't built in: there are a lot of subtleties to how exactly it works, and people might not agree on these. For example, git-absorb seems to have certain design goals that I don't agree with; I have written a longish document about that if you're interested. [2]

[1] <https://github.com/jesseduffield/lazygit/blob/master/
     docs/Fixup_Commits.md#finding-the-commit-to-create-a-fixup-for>

[2] <https://github.com/jesseduffield/lazygit/blob/master/docs/
     dev/Find_Base_Commit_For_Fixup_Design.md>

On Sun Nov 10, 2024 at 8:55 AM CET, Martin Imre wrote:

There are few problems, one which is the implementation language: git-absorb is Rust and git-fixup is bash (using arrays and other non-POSIX constructs).

Documentation/howto/new-command.txt declares:

    Most subcommands are written in C or shell.  A few are written in
    Perl.

    (And Python scripts are allowed for some specific tasks, namely GUI)

Shell script here quite emphatically means POSIX shell (or at least not using widely non-POSIX constructs like arrays), not bash. In order to even be able to consider any of these commands to be submitted to git proper, it would have to be ported first.

Best,

Matěj

On Mon, 11 Nov 2024 03:53:47 +0100, Matěj Cepl wrote:

fwiw, i just stumbled over https://github.com/torbiak/git-autofixup which is written in perl. no idea how good it is compared to git-absorb.

On Sat, Nov 9, 2024, at 12:41, Martin Imre wrote:

This could be useful for a lot of commands. I use git-notes(1) a lot (just as a niche example). I often wanna just get a list of the last commits (e.g. `@{u}..`) when I want to edit a note. (I should try to use fzf for that, thanks by the way!)

I’m imagining that some RFC implementation of this could get replies like “but why just for `git commit --fixup/--squash…`?”

As far as third-party programs are concerned: see this section of the Lazygit readme:[1]

Not the exact same thing of course. You don’t get intermediary fixup commit since it just runs interactive rebase in the background (so it runs an uninteractive rebase…).

I haven’t tried Lazygit myself.

🔗 1: https://github.com/jesseduffield/lazygit