Function: projectile--command-history-key

projectile--command-history-key is a byte-compiled function defined in projectile.el.

Signature

(projectile--command-history-key PROJECT-ROOT)

Documentation

Return the key PROJECT-ROOT's command history is stored under.

That's PROJECT-ROOT itself, unless projectile-command-history-scope asks for a repository-wide history and the repository can be identified - then it's a spelling of the repository, so that every checkout of it reaches the same history.

The upstream is preferred over the repository directory because it is the broader of the two: worktrees of one repository agree on it, and so do separate clones, which is the same arrangement done by hand. A repository with no upstream falls back to the directory its checkouts share, which still covers its worktrees.

Two consequences worth knowing. The key follows the remote, so pointing a repository at a new upstream moves it to a fresh history. And this picks one of the two keys where projectile-same-repo-p accepts either, so checkouts that disagree about having a remote at all - an hg share working directory whose source configures a default path and which doesn't - are one repository for switching purposes but keep separate histories.

Source Code

;; Defined in ~/.emacs.d/elpa/projectile-20260820.1509/projectile.el
(defun projectile--command-history-key (project-root)
  "Return the key PROJECT-ROOT's command history is stored under.

That's PROJECT-ROOT itself, unless `projectile-command-history-scope' asks
for a repository-wide history and the repository can be identified - then
it's a spelling of the repository, so that every checkout of it reaches the
same history.

The upstream is preferred over the repository directory because it is the
broader of the two: worktrees of one repository agree on it, and so do
separate clones, which is the same arrangement done by hand.  A repository
with no upstream falls back to the directory its checkouts share, which
still covers its worktrees.

Two consequences worth knowing.  The key follows the remote, so pointing a
repository at a new upstream moves it to a fresh history.  And this picks
one of the two keys where `projectile-same-repo-p' accepts either, so
checkouts that disagree about having a remote at all - an `hg share'
working directory whose source configures a `default' path and which
doesn't - are one repository for switching purposes but keep separate
histories."
  (or (and (eq projectile-command-history-scope 'repository)
           (let ((identity (projectile-repo-identity project-root)))
             (or (plist-get identity :remote)
                 (plist-get identity :repo))))
      project-root))