mirror of
https://github.com/jesseduffield/lazygit.git
synced 2026-09-12 00:26:24 -04:00
8b99a3c949
The rebase.updateRefs feature of git is very useful to rebase a stack of branches and keep everything nicely stacked; however, it is usually in the way when you make a copy of a branch and want to rebase it "away" from the original branch in some way or other. For example, the original branch might sit on main, and you want to rebase the copy onto devel to see if things still compile there. Or you want to do some heavy history rewriting experiments on the copy, but keep the original branch in case the experiments fail. Or you want to split a branch in two because it contains two unrelated sets of changes; so you make a copy, and drop half of the commits from the copy, then check out the original branch and drop the other half of the commits from it. In all these cases, git's updateRefs feature insists on moving the original branch along with the copy in the first rebase that you make on the copy. I think this is a bug in git, it should create update-ref todos only for branches that point into the middle of your branch (because only then do they form a stack), not when they point at the head (because then it's a copy). I had a long discussion about this on the git mailing list [1], but people either don't agree or don't care enough. So we fix this on our side: whenever we start a rebase for whatever reason, be it interactive, non-interactive, or behind-the-scenes, we drop any update-ref todos that are at the very top of the todo list, which fixes all the above-mentioned scenarios nicely. I will admit that there's one scenario where git's behavior is the desired one, and the fix in this PR makes it worse: when you create a new branch off of an existing one, with the intention of creating a stack of branches, but before you make the first commit on the new branch you realize some problem with the first branch (e.g. a commit that needs to be reworded or dropped). It this case you do want both branches to be affected by the change. In my experience this scenario is much rarer than the other ones that I described above, and it's also much easier to recover from: just check out the other branch again and hard-reset it to the rebased one. [1] https://public-inbox.org/git/354f9fed-567f-42c8-9da9-148a5e223022@haller-berlin.de/ |
||
|---|---|---|
| .. | ||
| checkout_by_name.go | ||
| create_tag.go | ||
| delete.go | ||
| delete_remote_branch_with_credential_prompt.go | ||
| detached_head.go | ||
| open_pull_request_no_upstream.go | ||
| open_with_cli_arg.go | ||
| rebase.go | ||
| rebase_abort_on_conflict.go | ||
| rebase_and_drop.go | ||
| rebase_cancel_on_conflict.go | ||
| rebase_copied_branch.go | ||
| rebase_does_not_autosquash.go | ||
| rebase_from_marked_base.go | ||
| rebase_to_upstream.go | ||
| rename.go | ||
| reset.go | ||
| reset_to_upstream.go | ||
| set_upstream.go | ||
| show_divergence_from_upstream.go | ||
| sort_local_branches.go | ||
| sort_remote_branches.go | ||
| suggestions.go | ||
| unset_upstream.go | ||