straight can't pickup new commit if remote HEAD branch has been renamed

[ikappaki]

What's wrong

It is possible that straight may fail to retrieve any new commits from the remote package repo, if the repository is already been cloned, and there has been a modification in the name of the remote HEAD branch (such as renamed from master to main).

Directions to reproduce

1. Create an new git repository with a single file with some text

~$ git init /tmp/issue-straight
Initialized empty Git repository in /tmp/issue-straight/.git/
~$ cd /tmp/issue-straight/
/tmp/issue-straight$ echo  123 > issue
/tmp/issue-straight$ git add issue
/tmp/issue-straight$ git commit -m "1"
[master (root-commit) 38aeb62] 1
 1 file changed, 1 insertion(+)
 create mode 100644 issue

2. In Emacs scratch buffer with straight.el loaded, fetch the repo using a custom recipy

(straight-use-package
'(issue :type git :repo "/tmp/issue-straight"))
;; => t

3. In the straight repo dir, check that the above repo has been checked out

/tmp/issue-straight$ cd ~/.config/emacs/straight/repos/issue
~/.config/emacs/straight/repos/issue$ git status
On branch master
Your branch is up to date with 'origin/master'.

nothing to commit, working tree clean
~/.config/emacs/straight/repos/issue$ cat issue
123
~/.config/emacs/straight/repos/issue$

4. Back at the source repo, add some more text to the file

~/.config/emacs/straight/repos/issue$ cd /tmp/issue-straight/
/tmp/issue-straight$ echo 456 >> issue
/tmp/issue-straight$ git commit -am "2"
[master 8ec7551] 2
 1 file changed, 1 insertion(+)

5. Back in Emacs, pull the changes with straight

(straight-pull-package "issue")
;; => nil

6. Back to the straight repo dir, check that the changes have been picked up by the straight pull

/tmp/issue-straight$ cd ~/.config/emacs/straight/repos/issue
~/.config/emacs/straight/repos/issue$ cat issue
123
456

7. Back at the source repo, rename the branch from master to main, and add some more changes

~/.config/emacs/straight/repos/issue$ cd /tmp/issue-straight/
/tmp/issue-straight$ git branch -m master main
/tmp/issue-straight$ git status
On branch main
nothing to commit, working tree clean
/tmp/issue-straight$ echo 789 >> issue
/tmp/issue-straight$ git commit -am "3"
[main 3fd338b] 3
 1 file changed, 1 insertion(+)
/tmp/issue-straight$ cat issue
123
456
789

8. Back in Emacs, do straight pull again

(straight-pull-package "issue")
;; => nil

9. Check the straight repo, the last commit is not picked up, there is no commit 3 in the repo

/tmp/issue-straight$ cd ~/.config/emacs/straight/repos/issue
~/.config/emacs/straight/repos/issue$ cat issue
123
456
~/.config/emacs/straight/repos/issue$ git log
commit 8ec75518099c0b5c4ea8363606717b6cf4b22d7f (HEAD -> master, origin/master, origin/HEAD)
Date:   Mon Nov 13 22:20:58 2023 +0000

    2

commit 38aeb629a8011b8dd024fd5ff9b3c7c8369eaba8
Date:   Mon Nov 13 22:10:39 2023 +0000

    1

Perhaps straight can check the remote HEAD branch before a fetch/pull and adjust the local HEAD accordingly when they diverge?

The above example scenario was encountered with emasql where I suspect somewhere in the last year their renamed their master branch to main, and I was stuck with a year's old master branch that could not be updated with straight pull

(straight-pull-package "emacsql")
;; => nil

~/.config/emacs/straight/repos/emacsql $ git log -1
commit 6b2e65bdf785364cf7c34c31fea5812e1e58c657
Author: Jonas Bernoulli <jonas@bernoul.li>
Date:   Sun Nov 27 22:46:37 2022 +0100

    Use new version string format for unreleased revisions
    
    "N-git" < "N"; but "N.50-git" > "N".
~/.config/emacs/straight/repos/emacsql $ git remote -v
origin	https://github.com/magit/emacsql.git (fetch)
origin	https://github.com/magit/emacsql.git (push)
~/.config/emacs/straight/repos/emacsql $ git symbolic-ref refs/remotes/origin/HEAD
refs/remotes/origin/master
~/.config/emacs/straight/repos/emacsql $ git ls-remote --symref origin HEAD
ref: refs/heads/main	HEAD
59de83a1276a5fbcf8a682b64bbdcf5e00c6ce8b	HEAD

Version information

• Emacs version: 29.1
• Operating system: unix

[raxod502]

Yeah, that sounds right to me. This is a bug. The caching logic needs to be updated to handle it correctly.