Allow pasting cherry-picked commits in a different worktree of the same repo#5688
Open
pnodet wants to merge 2 commits into
Open
Allow pasting cherry-picked commits in a different worktree of the same repo#5688pnodet wants to merge 2 commits into
pnodet wants to merge 2 commits into
Conversation
…itch The cherry-pick clipboard lives in GuiRepoState.Modes, and we keep a separate GuiRepoState per worktree (RepoStateMap is keyed by the worktree path). Switching worktrees swaps in that worktree's own state, whose clipboard is empty, so pasting is disabled. The copied commits aren't cleared; they're stranded on the previous worktree's state and reappear when switching back.
Copied commits are referenced by hash, and hashes resolve identically in every worktree of a repo (shared object database), so there's no reason pasting shouldn't work after switching worktrees. Move the clipboard out of the per-worktree GuiRepoState into a per-repo SharedRepoState, keyed by the repo's common git dir; every worktree's Modes.CherryPicking now points at the same instance. Submodules and unrelated repos have different git dirs, so they keep isolated clipboards. As a side effect, cancelling a cherry-pick in one worktree now correctly clears it in all of them.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Copying commits with
c/Cand then switching to another worktree of the samerepo would disable pasting with
V("No copied commits"). The copied commitsweren't actually cleared — the clipboard lives in
GuiRepoState.Modes, and wekeep a separate
GuiRepoStateper worktree, so the selection was stranded onthe previous worktree's state (it even reappeared when switching back).
There's no git-level reason for this limitation: pasting runs
git cherry-pick <hashes>, and hashes resolve identically in every worktree ofa repo since they share one object database.
This PR moves the clipboard out of the per-worktree
GuiRepoStateinto a newSharedRepoState, of which there is one instance per repo, keyed by the repo'scommon git dir. Every worktree's
Modes.CherryPickingnow points at the sameinstance. The common git dir is shared by all worktrees of a repo (including
worktrees of bare repos) but distinct for submodules and unrelated repos, so
those keep isolated clipboards.
Side effects of sharing the whole struct, both intended:
Esc) in one worktree now clears it in all ofthem.
highlight) in the others too, while still allowing a repeat paste, matching
the existing single-worktree behavior after a paste.
The first commit adds an integration test demonstrating the old behavior; the
second contains the fix and flips the test to the new expectation.