Open devinrhode2 opened 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.
A cheap feature could be some warnings to users who ARE heavily editing git-rebase-todo
: https://github.com/gitkraken/vscode-gitlens/issues/2358
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-todo
file (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-todo
and.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
~/.gitlens
or.git/gitlens
.Fourth, given a history manager, whenever a git rebase starts, copy the contents of
.git/rebase-merge/git-rebase-todo
intogrs
. As git rebase continues, git will copy lines from.git/rebase-merge/git-rebase-todo
into.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
done
andgit-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.