lazygit
lazygit copied to clipboard
jesseduffield
support rebasing from a specific commit
Is your feature request related to a problem? Please describe.
I want to be able to rebase from a specific commit onto another branch i.e. git rebase --onto baseBranch COMMIT_SHA. This is good for when your rebase has changed a lot and you don't want to replay the base branch's original commits back on top of the new ones (this often causes conflicts).
Describe the solution you'd like We need a way to both select the base branch as well as the base commit on the current branch. I'm thinking the rebase confirmation when you press 'r' on a branch becomes a rebase menu where one option is to specify the base commit. After selecting that, focus would be given to the local commits context to select the base commit. Then when you select it the rebase begins.
Describe alternatives you've considered We could be stateful and actually mark the base commit ourselves before opening the rebase menu. That way it's implicit that that's the commit you want to rebase from. This would be easier to implement in terms of the UI and also would mean that subsequent rebases don't require you to re-select that commit. The complexity would be added in maintaining the state across lazygit runs in a file, and also handling things like rebase events that remove that commit SHA (we could simply remove the base commit marker in those situations and leave it up to the user to re-set it). I'm actually thinking this approach makes more sense now.
Additional context Just found myself needing this today
This is definitely the one feature I'm missing that I would use pretty much every day.
Manually typing git rebase --onto etc... is quite a hassle.
Other than that, lazygit has been a breeze to work with.
@tzwaan I am also missing this feature, but every day? I'd be curious to learn more about the workflows you are using that require this, maybe something can be improved about them? (I'm not saying you are doing something wrong, I'm just curious.)
To elaborate: back when git didn't have support for rebasing a stack of branches as a whole using rebase --update-refs, I also needed it almost daily. Rebasing the bottom-most branch of a stack would then require manually rebasing the other branches onto it again, and the only way to do that was using rebase --onto. Now that I have rebase.updateRefs set to true in my global git config I don't need to do this any longer. Having to use --onto still happens occasionally (e.g. when a coworker helpfully pushes a fixup commit onto the bottom-most branch of my stack), but much more rarely.
Thanks for telling about this! This seems to be a new addition that solves a lot of my problems too!
I was not aware of the --update-refs functionality. Definitely going to check that out. That will likely remove a lot of the pains I was having.
Edit: for context, at my job, we squash-merge PRs into main, but often have stacks of multiple small PRs in succession and in parallel. So it looks like --update-refs will be my savior here.
This has become my top missing feature recently (yes, even though --update-refs exists), so I decided to start working on it. I agree that the second approach outlined above makes more sense. Before I spend a lot of time, a few questions about what you said above:
and also would mean that subsequent rebases don't require you to re-select that commit.
I'm a bit confused, I can't imagine a situation where you would reuse the marked base commit for another rebase. For the same branch it doesn't make sense, because that branch has just moved; and for a different branch it would only make sense if you have several branches sitting on the same base branch, but I've never been in that situation myself, so I'm having a hard time understanding what kind of workflow that is. My thought was that if you rebase from a marked base commit, we'd unmark the commit as part of that operation. (Side note: I'd also wish this to happen for cherry-picks; I have never needed to cherry-pick a commit to more than one place.)
The complexity would be added in maintaining the state across lazygit runs in a file
I don't think we need to bother. I see this as very similar to cherry-picking commits; the state is just gone if you quit.
and also handling things like rebase events that remove that commit SHA (we could simply remove the base commit marker in those situations and leave it up to the user to re-set it)
Again, I wouldn't bother doing anything here. I don't see the marker as very long-lived; the typical workflow is to mark a base commit, then go to the branches panel, pick the rebase target, hit r, and the marked commit is gone. I wouldn't worry about what happens if the user does other things in between.