Share the command history across a repository's checkouts - #2152
Merged
Conversation
Working on two branches means two directories, and the commands you build and test the project with are the same in both. Until now each checkout learned them separately, so a worktree made this morning greeted you with an empty history and you retyped everything. The per-command-type histories - the ones behind M-p at a prompt - are now keyed by the repository rather than by the directory, so a fresh worktree or a second clone offers the commands the project is actually built with. That's what `projectile-repo-identity' was for. Two things deliberately stay local to the checkout you're in, because both act without asking and a remembered command can carry absolute paths back into the checkout it was typed in: what a prompt is pre-filled with, and what `projectile-repeat-last-command' replays. The first draft shared the combined history too, and in a worktree the repeat binding then rebuilt the *other* tree unprompted - the browsable history is safe to share precisely because reaching for it is a deliberate act. The histories are persisted, so an upgrade would have walked into a project you have been building for years with nothing in hand. A history found under the old per-root key is adopted as the repository's.
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.
Fixes #1786.
Working on two branches means two directories, and you build and test the project the same way in both. Until now each checkout learned the commands separately, so a worktree made this morning greeted you with an empty history and you retyped everything.
The per-command-type histories - the ones behind
M-pat a prompt - are now keyed by the repository rather than the directory, so a fresh worktree or a second clone offers the commands the project is actually built with. This is what the identity layer from #2147 was for.Two things deliberately stay local to the checkout you're in: what a prompt is pre-filled with, and what
projectile-repeat-last-commandreplays. My first draft shared the combined history too, and a review caught what that meant in practice - in a worktree the repeat binding rebuilt the other tree, unprompted, while you thought you were building the one you were sitting in. The browsable history is safe to share precisely because reaching for it is a deliberate act.Same review caught that these histories are persisted through savehist, so keying them differently would have silently emptied every existing project's history on upgrade day - the exact opposite of the point. A history found under the old per-root key is adopted as the repository's.
projectile-command-history-scopeset toprojectrestores the old per-directory behaviour, and it's safe as a file-local so you can set it for the odd repo whose clones are genuinely built differently.