Use `git history reword` instead of `git rebase -i` for rewording non HEAD commits

[jaseemabid]

Is your feature request related to a problem? Please describe.

I noticed that lazygit is using git rebase -i ... for rewording older commits; but git very recently shipped a core feature to make this slightly simpler.

See https://github.blog/open-source/git/highlights-from-git-2-54

git history reword opens your editor with the specified commit’s message and rewrites it in place, updating any branches that descend from that commit. Unlike git rebase, it doesn’t touch your working tree or index, and it can even operate in a bare repository.

Describe the solution you'd like

When you press r on an old commit, call git history reword HASH instead of what we do now if the installed git version is new enough.

Describe alternatives you've considered

N/A

Additional context

I'm a BIG fan of lazygit and use it way too much daily. I'm not a contributor to this project yet, but I can give it a try to implement this feature if @jesseduffield thinks it's worthwhile.

[stefanhaller]

You don't say why you are suggesting to switch to the new command.

I could see two possible reasons:

• it might be faster (did you measure?)
• it updates descendent branches by default
• any other reasons?

That second point is actually a reason not to use it, because the behavior would be inconsistent with all the other rebasing operations that lazygit offers (e.g. dropping or moving commits, and many others). Today, users can control whether they want to update a descendent branch (only one) via the rebase.updateRefs config for all those operations; git history has an option --update-refs that make it work like the others when rebase.updateRefs is true, but it doesn't accept a none value, so we can't turn that behavior off.

Also, git history doesn't support branches that contain merge commits, whereas our current implementation does. Another inconsistency that could be confusing.

Given all this, I just don't think it's worth spending time on this.

but I can give it a try to implement this feature if @jesseduffield thinks it's worthwhile.

This project no longer accepts pull requests. Also, Jesse no longer maintains this project, it's me these days.

[jonathanharg]

I would also appreciate being able to use git history reword from within lazygit. Maybe I can shed some light on why this would be useful, at least for me.

As you mentioned, the main upsides is speed. Most of my time I work on a git-svn monorepo that's disgustingly large, to the point where rebasing any more than a couple commits can take minutes. Prior to 2.54 I avoided rewording entirely, and waited to make any modifications in one large interactive rebase. With git history reword I can make these changes almost immediate (outside lazygit).

Generally, not touching the worktree during a reword is quite nice. Previously I've found myself unintentionally cancelling or breaking builds that are running in the background because a source file has been modified to during a rebase. Although this is just another symptom of having a large repository and slow build times, it would be nice to not have to worry about it.

I can see your reservations. Most users wouldn't know, notice, or care, if git history reword was used instead of git rebase -i. It does come with some drawback like you mentioned, and it's still marked as experimental. However, for anyone in a large monorepos it's a bit of a life saver. Putting it behind some sort of feature flag or config option with an accompanying note would make more sense than directly replacing it for all users.

If it's not worth the time I may look into writing a patch/forking, it's unlikely I'm the only one who runs into these issues.

[stefanhaller]

@jonathanharg This is useful input, thanks. Minutes, seriously? That's bad.

Good point about breaking a running build when rebasing, especially when it doesn't look to the user like a rebase is happening. I ran into this too, and it can be confusing and annoying. However, I think I'm running into it more often when amending changes to earlier commits, so there's another one of those inconsistencies: reword no longer breaks running builds, but amending or moving commits still does.

Another big advantage of git history is that it can reword commits when you are stopped in the middle of a rebase, which is an annoying limitation of our current reword approach.

So it starts to look like it would actually be a good idea to use it, so I'll put that on the todo list. My main open questions are:

• should it be used always when available, or do we want a config? And if so, should it be opt-in or opt-out?
• should it keep its default of --update-refs=branches (which is arguably more useful in most circumstances), or should we force it to --update-refs=head to make it behave more similar to the other rebasing operations (when rebase.updateRefs is true, that is)?

[ambyjkl]

My take on --update-refs=branches vs --update-refs=head is --update-refs=head by default, since it preserves existing behavior, and having a config option or ui option (maybe call it reword globally or something) for changing behavior is ideal.

[ambyjkl]

Also I'm glad git is finally adding ways to edit history without a rebase and would love to see these land in lazygit. Plus it would be great if they rework rebase to update the working tree lazily: only upon a merge conflict. In my case, I use rebase all the time so I have built hacks to discard unnecessary changes to the worktree using overlayfs: I mount a tmpfs overlay on top of the worktree during a rebase which I can unmount after it's done to discard all file touches.

[jonathanharg]

@stefanhaller Thanks for your reply.

reword no longer breaks running builds, but amending or moving commits still does.

One less opportunity for borked builds sounds like a win to me. Maybe we'll get git-history fixup soon enough. It also looks like git-replay is going to become more prominent with its Jujutsu-style functionality, which I can't complain about either.

should it be used always when available, or do we want a config? And if so, should it be opt-in or opt-out?

Personally, I think while the feature is still marked as experimental it makes sense to be opt-in. Those who would benefit from it (e.g. me) would look to enable it, others don't have to worry about a change in behaviour. I can imagine it'll eventually become the de facto way to reword, and when that happens it may make sense for it to become opt-out.

should it keep its default of --update-refs=branches (which is arguably more useful in most circumstances), or should we force it to --update-refs=head to make it behave more similar to the other rebasing operations (when rebase.updateRefs is true, that is)?

Since it's not actually a rebase operation, I don't think it makes sense to mirror rebase options or be effected by them. I can see why you'd want to make --update-refs configurable, but it feels to me like this would be a case-by-case option rather than a global setting. I'm not against @ambyjkl 's suggestion of it being a different command (perhaps a "Reword just on this branch"), but I can see why you might want to avoid overcomplicating it and adding command bloat. Although I think it makes sense to mirror gits defaults here.

If I'm rewording I'm not actually thinking about the underlying rebase. Normally I'm just thinking about spelling. For that reason I don't feel it's that important to me for the operation to match rebase semantics.

Minutes, seriously? That's bad.

It's an ~120 GB .git folder 😉 , the good new for you is that lazygit is the only gui I've found that can handle it.

[ambyjkl]

It's an ~120 GB .git folder

That's quite impressive, @jonathanharg i'd like to pick your brain on how you manage to keep such a large git repo performant, I've got a git repo with an 8GB .git folder and 500k tracked files, and while i have turned on a bunch of features like feature.manyFiles, core.fsmonitor, core.untrackedCache, etc., I think I could still squeeze more perf out of it.

[oliverpool]

FYI git history now supports reword, split and fixup (via https://lalitm.com/post/git-history/)

So "amending" commits should become less painful. "moving commits" does seem supported (yet).