devinrhode2
commented
1 year ago Keeping a persistent history of this file across rebases can help a lot in one situation: You have a branch which is getting too big, and you make more than ~3 changes to git-rebase-todo. Combined with rerere, this feature could mean "big" rebase changes (heavily editing git-rebase-todo) is to be less feared.
Although, I still think heavily editing git-rebase-todo in any ONE particular rebase is still a bad practice. Often rebase conflicts come in pairs, if you make one change, you get 2 conflicts, those two conflicts are often mirror images of each other. If you make 3 changes you could have 6 conflicts and not be able to resolve conflicts as quickly.
For this feature to work seamlessly, gitlens would have to do all that it can to avoid letting you directly modify the
.git/rebase-merge/git-rebase-todofile (and it's sibling,.git/rebase-merge/done).A primitive version of this feature could work as follows: First, define a "proxy" that intercepts reads/writes to these two files from git:
.git/rebase-merge/git-rebase-todoand.git/rebase-merge/done. (Could watch the files, etc)Second, create an empty file named
grs. ("git-rebase-state") (Short name is nice for someone that frequently rebases, and would therefore want local history of this file). Also, tell git to ignore this file somehow (traditional in-repo .gitignore is probably best).Third, create a history manager for this file. The best ui is no ui - ideally ctrl+z "just works", but inevitably we will probably want some ui here. Ideally: convert the "undo" buffer into commits, or replicate vscode's undo buffer logic, and commit this into a one-file repo somewhere
~/.gitlensor.git/gitlens.Fourth, given a history manager, whenever a git rebase starts, copy the contents of
.git/rebase-merge/git-rebase-todointogrs. As git rebase continues, git will copy lines from.git/rebase-merge/git-rebase-todointo.git/rebase-merge/done, these changes could be given special demarcation in the history ui.Given this foundation, a variety of "niceties" could be added: First most obvious one, is some sort of "pointer" for where the rebase is currently at, a demarcation of the contents of
doneandgit-rebase-todo. This can scope creep into a full blown reflog ui, such as git graph: https://marketplace.visualstudio.com/items?itemName=mhutchie.git-graphSecond, Some indication of what sha a rebase is rebasing onto would be useful. Perhaps scrolling away from HEAD reveals a read-only history of commits you are rebasing onto (perhaps literally git log --oneline).
.git/rebase-merge/git-rebase-todo, we'd scroll up, but I'm also an avid user of Github's desktop app and github.com, where you are always scrolling down. Infinite scroll implementations usually involve the user scrolling down, may be useful to take the opinionated stance with latest=top, oldest=bottom, and don't give an option to scroll up, unless users really want it.