jesseduffield
Rebase broken when filtering on file
Describe the bug When we're filtering commits based on whether they contain a file, we can get conflicts upon trying to remove a file from a given commit via the custom patch builder.
I assume this is because it decides which commits need rebasing based on what's in the commits panel, which causes problems given that they're filtered.
To Reproduce No time to come up with repro steps atm, but can do later.
Expected behavior Rebases happen exactly the same as they would if you had not filtered by file.
As a stopgap we could disable the custom patch rebase functionality when in file-filter mode.
Version info: commit=4ca52373b6c660a93fbe19dc104d1d7a815ea555, build date=2023-04-15T04:36:33Z, build source=unknown, version=4ca52373, os=darwin, arch=amd64, git version=2.33.0
Not just conflicts; on master, this would actually drop all commits except the filtered ones.
This should be fixed by #2552, specifically by commit c76cf985c9b3.
It's the same problem that would happen (on master) for "drop", "fixup", "reword", and many others if we allowed them in filtered mode; but we error out for these in filtered mode to prevent this.
Which means that after #2552 is merged we should be able to enable most of these in filtered mode, e.g. rewording commits. (I haven't tested this yet, though, but I'm pretty sure it would work.) For some actions it will probably still make sense to prevent them in filtered mode; for example, moving commits up or down. While it would still work correctly, you wouldn't see the commit move if it's neighbor commits are filtered out, so this could be confusing.
