mirror of
https://github.com/jesseduffield/lazygit.git
synced 2026-09-11 08:06:25 -04:00
1fdcc29277
It is a bad idea to read a git-rebase-todo file, remove some update-ref todos, and write it back out behind git's back. This will cause git to actually remove the branches referenced by those update-ref todos when the rebase is continued. The reason is that git remembers the refs affected by update-ref todos at the beginning of the rebase, and remembers information about them in the file .git/rebase-merge/update-refs. Then, whenever the user performs a "git rebase --edit-todo" command, it updates that file based on whether update-ref todos were added or removed by that edit. If we rewrite the git-rebase-todo file behind git's back, this updating doesn't happen. Fix this by not updating the git-rebase-todo file directly in this case, but performing a "git rebase --edit-todo" command where we set ourselves as the editor and change the file in there. This makes git update the bookkeeping information properly. Ideally we would use this method for all cases where we change the git-rebase-todo file (e.g. moving todos up/down, or changing the type of a todo); this would be cleaner because we wouldn't mess with git's private implementation details. I tried this, but unfortunately it isn't fast enough. Right now, moving a todo up or down takes between 1 and 2ms on my machine; changing it to do a "git rebase --edit-todo" slows it down to over 100ms, which is unacceptable. |
||
|---|---|---|
| .. | ||
| bisect | ||
| branch | ||
| cherry_pick | ||
| commit | ||
| config | ||
| conflicts | ||
| custom_commands | ||
| demo | ||
| diff | ||
| file | ||
| filter_and_search | ||
| filter_by_author | ||
| filter_by_path | ||
| interactive_rebase | ||
| misc | ||
| patch_building | ||
| reflog | ||
| shared | ||
| staging | ||
| stash | ||
| submodule | ||
| sync | ||
| tag | ||
| ui | ||
| undo | ||
| worktree | ||
| test_list.go | ||
| test_list_generator.go | ||
| tests.go | ||