Visit github issue with forge without cloning entire repo

[ParetoOptimalDev]

This is supported as per magit/forge#102, but it's not quite straight-forward or provided in a single function. It doesn't seem too difficult to add though given consult-gh will have the info to correctly call both forge-add-repostiory and if it supports it, providing the topic id from the consult-gh search.

[ParetoOptimalDev]

It looks like consult-gh-forge--issue-view would need modified somehow.

[armindarvish]

@ParetoOptimalDev Can you please elaborate? Currently, consult-gh-forge--issue-view-action does exactly what you are asking for. It does not clone the entire repo, and you can see the issues and interact with them as you would normally do in forge. This comment itself is being sent from forge right now!

[ParetoOptimalDev]

@ParetoOptimalDev Can you please elaborate? Currently, consult-gh-forge--issue-view-action does exactly what you are asking for. It does not clone the entire repo, and you can see the issues and interact with them as you would normally do in forge. This comment itself is being sent from forge right now!

When I tried using it on the nixpkgs repo it hung, but maybe it just took longer than I expected for the bare repo.

Will check again.

[armindarvish]

@ParetoOptimalDev Can you please share the name of the repo and the issue number you were trying to load?

Sometimes if there are a lot of comments and posts under an issue it can take some time to load it, which has nothing to do with consult-gh. This would also take a long time to load in forge without consult-gh unless you clone the repo and have everything stored in the local database. Even in the browser, loading everything would take a long time. When there are many comments and posts, the website loads a limited number of entries and you have to keep clicking on "Load more ..." To see them all which is even slower. For an example try looking at minad/consult#6

This 917 comments, and the browser only loads about 50 of them! I can still open this in consult-gh using forge but it takes several seconds to load. If you do this often, then you need to increase the value of consult-gh-forge-timeout-seconds

There are of course ways to improve the behavior to load a limited number of entries, but if you are using forge to view the issues, that has to happen in forge (which probably does not make sense since forge uses local database anyway) and not in consult-gh!

[ParetoOptimalDev]

I just replicated using this issue:

NixOS/nixpkgs#253198

I got to it by using consult-gh-search-repo, entering nixos/nixpkgs, searching haskell, and then hitting enter on the "spago" issue that comes up first, aka calling consult-gh-forge--issue-view-action.

I did notice that when using consult-gh-list-issues I don't seem to have this problem. Going to wait and see if consult-gh-search-repo ever completes and will look at the location forge clones to to see if it cloned the full repo to verify.

Edit: Here is a debug trace using debug on quit during the "hang":

  regexp-opt-group(("savannah.gnu.org" "sr.ht" "suckless.org"))
  regexp-opt-group(("kernel.org" "savannah.gnu.org" "sr.ht" "suckless.org") t t)
  regexp-opt-group((".kernel.org" ".savannah.gnu.org" ".sr.ht" ".suckless.org"))
  regexp-opt-group((".kernel.org" ".savannah.gnu.org" ".sr.ht" ".suckless.org" "hub.com" "lab.com" "lab.gnome.org") t t)
  regexp-opt-group(("git.kernel.org" "git.savannah.gnu.org" "git.sr.ht" "git.suckless.org" "github.com" "gitlab.com" "gitlab.gnome.org"))
  regexp-opt-group(("git.kernel.org" "git.savannah.gnu.org" "git.sr.ht" "git.suckless.org" "github.com" "gitlab.com" "gitlab.gnome.org" "repo.or.cz" "salsa.debian.org"))
  regexp-opt-group(("framagit.org" "git.kernel.org" "git.savannah.gnu.org" "git.sr.ht" "git.suckless.org" "github.com" "gitlab.com" "gitlab.gnome.org" "repo.or.cz" "salsa.debian.org"))
  regexp-opt-group(("code.orgmode.org" "codeberg.org" "framagit.org" "git.kernel.org" "git.savannah.gnu.org" "git.sr.ht" "git.suckless.org" "github.com" "gitlab.com" "gitlab.gnome.org" "repo.or.cz" "salsa.debian.org"))
  regexp-opt-group(("bitbucket.org" "code.orgmode.org" "codeberg.org" "framagit.org" "git.kernel.org" "git.savannah.gnu.org" "git.sr.ht" "git.suckless.org" "github.com" "gitlab.com" "gitlab.gnome.org" "repo.or.cz" "salsa.debian.org") "\\(" nil)
  regexp-opt(("github.com" "gitlab.com" "salsa.debian.org" "framagit.org" "gitlab.gnome.org" "codeberg.org" "code.orgmode.org" "bitbucket.org" "git.savannah.gnu.org" "git.kernel.org" "repo.or.cz" "git.suckless.org" "git.sr.ht") t)
  forge--url-regexp()
  forge--split-url("https://github.com/NixOS/nixpkgs")
  #f(compiled-function (url &optional remote demand) "Return the repository at URL." #<bytecode -0x147062aef454301e>)("https://github.com/NixOS/nixpkgs")
  apply(#f(compiled-function (url &optional remote demand) "Return the repository at URL." #<bytecode -0x147062aef454301e>) "https://github.com/NixOS/nixpkgs" nil)
  forge-get-repository("https://github.com/NixOS/nixpkgs")
  consult-gh-forge--add-topic("https://github.com/NixOS/nixpkgs" 253198)
  consult-gh-forge--issue-view("NixOS/nixpkgs" "253198")
  #f(compiled-function (cand) #<bytecode -0x28cea9b77030924>)(#("253198:Broken package `spago`" 0 29 (:issue "253198" :repo "NixOS/nixpkgs" :status "open" :description "Broken package `spago`" :tags "0.kind: bug" :date "2023-09-08T02:35:32Z")))
  consult--multi(((:category 'consult-gh-issues :items (#("250091:Broken Haskell packages `..." 0 86 ...) #("243553:haskell gio system depend..." 0 47 ...) #("248979:Haskell: support cross-co..." 0 91 ...) #("239357:Changing pkgsMusl.haskell..." 0 110 ...) #("36200:Cross Compiling Haskell to..." 0 40 ...) #("43795:Fully static Haskell execu..." 0 55 ...) #("243512:List of available haskell..." 0 87 ...) #("220835:Get pkgsCross.wasi32.buil..." 0 83 ...) #("208959:pkgsStatic.buildPackages...." 0 78 ...) #("249962:Build failure: nvfetcher" 0 31 ...) #("253198:Broken package `spago`" 0 29 ...) #("251884:Documentation: callCabal2..." 0 35 ...) #("130556:haskell: cabal unable to ..." 0 87 ...) #("212192:haskell.packages.ghc94: p..." 0 133 ...) #("250833:GHC962 fails to build usi..." 0 47 ...) #("40128:Haskell deps that use back..." 0 48 ...) #("56493:Cross-compiling haskell ex..." 0 53 ...) #("20800:Haskell jni package needs ..." 0 46 ...) #("229843:Package request: SimpleX ..." 0 47 ...) #("225895:haskell-language-server p..." 0 65 ...) #("224197:`dontCheck` for haskell p..." 0 67 ...) #("235960:haskell.packages.*: overl..." 0 98 ...) #("123860:haskell-updates: operatio..." 0 65 ...) #("56120:Cannot cross-build Haskell..." 0 48 ...) #("33768:haskell.compiler.ghcjs ins..." 0 52 ...) #("26852:Haskell: overrideScope los..." 0 63 ...) #("30114:haskell: buildTools no lon..." 0 51 ...) #("44120:stack (haskell tool) docke..." 0 48 ...) #("51987:Introduce DWARF-enabled Ha..." 0 49 ...) #("52439:Segfault in Setup when bui..." 0 54 ...)) :face 'consult-gh-default-face :action #f(compiled-function (cand) #<bytecode -0x28cea9b77030924>) :annotate #<subr F616e6f6e796d6f75732d6c616d626461_anonymous_lambda_61> :state consult-gh--issue-preview :default t :history t :sort t)) :prompt "Select Issue(s): " :require-match t :sort t :group consult-gh--issue-group :history consult-gh--issues-history :category consult-gh-issues :sort t :preview-key "M-o")
  consult-gh-search-issues()
  funcall-interactively(consult-gh-search-issues)
  command-execute(consult-gh-search-issues record)
  execute-extended-command(nil "consult-gh-search-issues" nil)
  funcall-interactively(execute-extended-command nil "consult-gh-search-issues" nil)
  command-execute(execute-extended-command)

[ParetoOptimalDev]

Nevermind, I have an issue with forge. Perhaps my version of forge isn't updated for emacs 29:

Debugger entered--Lisp error: (args-out-of-range #<buffer *forge-issue-list: nixos/nixpkgs*> 0 1)
  forge--topic-by-forge-short-link-at-point(("#") forge-get-issue)
  forge--issue-by-forge-short-link-at-point()
  forge-topic-at-point()
  forge-current-topic()
  byte-code("\300 \211\203\17\0\301\1\302\"\262\1\202\24\0\303\304!\262\1C\207" [forge-current-topic eieio-oref id forge-read-topic "View topic"] 4)
  command-execute(forge-visit-topic)

[ParetoOptimalDev]

It also has a similar hang even after fully cloning the repo, but really leaning towards this being a forge or forge on emacs 29 issue.

[armindarvish]

@ParetoOptimalDev Yes, I just tested with that same issue (NixOS/nixpkgs#253198) and it works just fine. Here is a screenshot for reference:

I am also on Emacs >29. There must be something with your forge setup that is causing this.I am closing this issue for now.

[ParetoOptimalDev]

I just verified using forge-20230901.1233 by debugging this function consult-gh calls:

(cl-defmethod forge-get-repository ((url string) &optional remote demand)
  "Return the repository at URL."
  (if-let ((parts (forge--split-url url)))
      (forge-get-repository parts remote demand)
    (when (memq demand forge--signal-no-entry)
      (error "Cannot determine forge repository.  %s isn't a forge url" url))))

The value of demand is full. It seems like maybe your version of forge is defaulting to nil and mine is defaulting to full for forge-get-repository.

A fix that would likely work for me is:

(defun consult-gh-forge--add-topic (url topic)
  "Add a repository to the forge database and only
pull individual topics when the user invokes `forge-pull-topic'. see forge documentation for `forge-add-repository'."
  (cl-letf (((symbol-function #'magit-toplevel)
             (lambda () (consult-gh--make-tempdir (string-join (cdr (forge--split-url url)) "/")))
             ))
    (let ((created (consult-gh-forge--add-repository url))
          (repo (forge-get-repository url)))
      (while (not repo)
        (sit-for 0.0001)
-        (setq repo (forge-get-repository url)))
+        (setq repo (forge-get-repository url nil nil)))
      (consult-gh-forge--pull-topic url topic)
      created
      )))

[ParetoOptimalDev]

After deleting the repo from forge and recreating it I can no longer reproduce this issue.

[ParetoOptimalDev]

This issue was resolved by doing forge-reset-database.

[ParetoOptimalDev]

Nevermind... I know the problem!

It only does a sparse clone the first time. The next time you call forge-get-repository after the first invocation created the repo in forges database it seems the second call clones the rest of it.