Giter Club home page Giter Club logo

gh.nvim's Introduction

         ██████╗ ██╗  ██╗   ███╗   ██╗██╗   ██╗██╗███╗   ███╗
        ██╔════╝ ██║  ██║   ████╗  ██║██║   ██║██║████╗ ████║
        ██║  ███╗███████║   ██╔██╗ ██║██║   ██║██║██╔████╔██║
        ██║   ██║██╔══██║   ██║╚██╗██║╚██╗ ██╔╝██║██║╚██╔╝██║ Powered by
        ╚██████╔╝██║  ██║██╗██║ ╚████║ ╚████╔╝ ██║██║ ╚═╝ ██║ litee.nvim
         ╚═════╝ ╚═╝  ╚═╝╚═╝╚═╝  ╚═══╝  ╚═══╝  ╚═╝╚═╝     ╚═╝

gh.nvim, initially, is a plugin for interactive code reviews which take place on the GitHub platform.

If you want to go straight to setup and configuration click here

If you're a visual learner you can check out the official gh.nvim guide. This is a work in progress as gh.nvim changes and matures.

This plugin was created due to the repeat frustration of performing code reviews of complex changes in the GitHub web UI.

The mentioned frustration seemed to boil down to a few major drawbacks which gh.nvim sets out to fix. These are:

  1. Lack of context during code review When viewing a pull request in a large code base its very likely that you're not sure of the full context of the change. The patch may change the way a function works, but you are not aware all the places this function may be called. Its difficult to safely say that the patch is OK and approve it.

    To alleviate this, gh.nvim will make the pull request code locally available on your file system.

  2. Lack of sufficient editor tools like LSP Because the pull request's code is made locally available all your LSP tools work as normal.

    In my previous point, this means performing a LSP call to understand all the usages of the editing function is now possible.

  3. Lack of automation when attempting to view the full context of a pull request. gh.nvim automates the process of making the pull request's code locally available. To do this, gh.nvim embeds a git CLI wrapper.

    When a pull request is opened in gh.nvim the remote is added locally, the branch is fetched, and the repo is checked out to the pull request's HEAD.

  4. Inability to edit and run the code in the pull request. Because the pull request's code is made available locally, its completely editable in your familiar neovim instance.

    This works for both for writing reviews and responding to reviews of your pull request.

    You can build up a diff while responding to review comments, stash them, check out your branch, and rebase those changes into your PR and push again. Much handier then jumping back and forth between neovim and a browser.

    Additionally, since the code is local and checked out on your file system, you can now run any local development environments that may exist. The environment will be running the pull request's code and you can perform sanity checks easily.

see doc/gh-nvm.txt for complete usage and more details.

Checkout my rational and demo video to get an initial idea of how gh.nvim works, why it works the way it does, and its look and feel.

Setup & Configuration

Before getting started with this plugin, make sure you have installed and configured both the git and gh CLI tools which are required for this plugin to work.

gh.nvim relies on Litee.nvim. To setup gh.nvim with the default configuration add the following:

Using lazy.nvim

{
    "ldelossa/gh.nvim",
    dependencies = {
        {
        "ldelossa/litee.nvim",
        config = function()
            require("litee.lib").setup()
        end,
        },
    },
    config = function()
        require("litee.gh").setup()
    end,
}

Using packer.nvim

use {
    'ldelossa/gh.nvim',
    requires = { { 'ldelossa/litee.nvim' } }
  }

Then call the setup function for both Litee.nvim and gh.nvim. Make sure you setup Litee.nvim before gh.nvim! The default configuration for gh.nvim is shown below (the default configuration for Litee.nvim can be found on it's Github page).

require('litee.lib').setup()
require('litee.gh').setup({
  -- deprecated, around for compatability for now.
  jump_mode   = "invoking",
  -- remap the arrow keys to resize any litee.nvim windows.
  map_resize_keys = false,
  -- do not map any keys inside any gh.nvim buffers.
  disable_keymaps = false,
  -- the icon set to use.
  icon_set = "default",
  -- any custom icons to use.
  icon_set_custom = nil,
  -- whether to register the @username and #issue_number omnifunc completion
  -- in buffers which start with .git/
  git_buffer_completion = true,
  -- defines keymaps in gh.nvim buffers.
  keymaps = {
      -- when inside a gh.nvim panel, this key will open a node if it has
      -- any futher functionality. for example, hitting <CR> on a commit node
      -- will open the commit's changed files in a new gh.nvim panel.
      open = "<CR>",
      -- when inside a gh.nvim panel, expand a collapsed node
      expand = "zo",
      -- when inside a gh.nvim panel, collpased and expanded node
      collapse = "zc",
      -- when cursor is over a "#1234" formatted issue or PR, open its details
      -- and comments in a new tab.
      goto_issue = "gd",
      -- show any details about a node, typically, this reveals commit messages
      -- and submitted review bodys.
      details = "d",
      -- inside a convo buffer, submit a comment
      submit_comment = "<C-s>",
      -- inside a convo buffer, when your cursor is ontop of a comment, open
      -- up a set of actions that can be performed.
      actions = "<C-a>",
      -- inside a thread convo buffer, resolve the thread.
      resolve_thread = "<C-r>",
      -- inside a gh.nvim panel, if possible, open the node's web URL in your
      -- browser. useful particularily for digging into external failed CI
      -- checks.
      goto_web = "gx"
  }
})

It's highly recommended to use gh.nvim with either fzf.lua or telescope to override vim.ui.select. If you use telescope, it will work out of the box. If you want to use fzf.lua, add the following snippet to your config:

vim.cmd("FzfLua register_ui_select")

Additionally, you may want to set up some which key bindings to help navigate all of the commands. Below you can find an example which key configuration that binds most of the commands. It also includes a keybinding for LTPanel which comes from Litee.nvim and allows you to toggle the panel so you can focus on the diff.Feel free to tweak to your liking.

local wk = require("which-key")
wk.register({
    g = {
        name = "+Git",
        h = {
            name = "+Github",
            c = {
                name = "+Commits",
                c = { "<cmd>GHCloseCommit<cr>", "Close" },
                e = { "<cmd>GHExpandCommit<cr>", "Expand" },
                o = { "<cmd>GHOpenToCommit<cr>", "Open To" },
                p = { "<cmd>GHPopOutCommit<cr>", "Pop Out" },
                z = { "<cmd>GHCollapseCommit<cr>", "Collapse" },
            },
            i = {
                name = "+Issues",
                p = { "<cmd>GHPreviewIssue<cr>", "Preview" },
            },
            l = {
                name = "+Litee",
                t = { "<cmd>LTPanel<cr>", "Toggle Panel" },
            },
            r = {
                name = "+Review",
                b = { "<cmd>GHStartReview<cr>", "Begin" },
                c = { "<cmd>GHCloseReview<cr>", "Close" },
                d = { "<cmd>GHDeleteReview<cr>", "Delete" },
                e = { "<cmd>GHExpandReview<cr>", "Expand" },
                s = { "<cmd>GHSubmitReview<cr>", "Submit" },
                z = { "<cmd>GHCollapseReview<cr>", "Collapse" },
            },
            p = {
                name = "+Pull Request",
                c = { "<cmd>GHClosePR<cr>", "Close" },
                d = { "<cmd>GHPRDetails<cr>", "Details" },
                e = { "<cmd>GHExpandPR<cr>", "Expand" },
                o = { "<cmd>GHOpenPR<cr>", "Open" },
                p = { "<cmd>GHPopOutPR<cr>", "PopOut" },
                r = { "<cmd>GHRefreshPR<cr>", "Refresh" },
                t = { "<cmd>GHOpenToPR<cr>", "Open To" },
                z = { "<cmd>GHCollapsePR<cr>", "Collapse" },
            },
            t = {
                name = "+Threads",
                c = { "<cmd>GHCreateThread<cr>", "Create" },
                n = { "<cmd>GHNextThread<cr>", "Next" },
                t = { "<cmd>GHToggleThread<cr>", "Toggle" },
            },
        },
    },
}, { prefix = "<leader>" })

gh.nvim's People

Contributors

axkirillov avatar bradsherman avatar dantesg avatar david-kunz avatar davidmh avatar fcbry avatar frederick888 avatar guillaumelagrange avatar jemershaw avatar ldelossa avatar lervag avatar m42e avatar metalelf0 avatar tochamateusz avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

gh.nvim's Issues

not defaulting to telescope with lazy.nvim

Hello, your plugin looks amazing and exactly what i've been looking for. Can't stand the temptation to go to function definition with octo knowing that it's not possible.

when I run GHOpenPr i get the regular ui view, not telescope. In the readme it's mentioned that it should default to telescope, however i don't see that and haven't been able to figure out where in the code that should be happening. I'm wondering if there's any guidance i'm missing or if this is something else.

Thank you for making the plugin again, really hopeful it solves the need i have

Loading a PR can get stuck at the "fetching checks" stage

While trying to open cilium/cilium#19159, I'm hitting an issue where gh.nvim gets stuck "fetching checks". It does not appear to proceed beyond this point.

For some context, at this time there are checks in various stages, including passed, failed, skipped and required-but-not-run (probably due to some upstream GitHub bug):
image

Bug: Fail to list PRs

macOS Monterey, non-M1, tested on nvim stable and nightly. I'm just using the default settings for everything. In a repo with an active pull request, calling :GHOpenPR returns a message of Failed to list PRs. Ensured that both plugins are installed and up. Is there some type of log that I can post here so debugging is easier?

Bitbucket integration

Hey, how hard will it be to integrate this plugin with bitbucket's pull requests and reviews?

Detach LSPs on left side of diff view

Things get real weird when LSP's are attached to the tmp file created to diff the original file and the changed file sititng locally on the FS.

Detach any LSPs on the tmp file on the left side of diff to avoid this.

Comment threads occasionally mismatch with GitHub UI presentation of the change

I don't have reproducible steps for this one just yet, but I noticed during a recent review that sometimes the threads don't post against the line that I expect. I created a thread against a line in a specific commit, I think the lines had some diff, then some existing code unchanged, then a couple more lines diff / added. Inside gh.nvim, it displays the comment thread correctly (according to how gh.nvim originally presented it), but on the github UI, the comment is actually posted against a line a couple of lines down.

At least one of the cases, I actually posted the comment against a line between the diff. Maybe the line calculation is slightly off if not commenting directly against the diff...?

I'll keep an eye out and post more details here again if I notice more details.

Feature request: Show diff between current and target branches in per-file diff view

At the moment in per-file diff views, it shows the difference from the common ancestor between current and target branches [1].

This gives different results from GitHub web. It'd be nice if this can be configured to head of target branch. (We all have to work with someone who just loves merging master/main into PR branches, don't we ;) )

[1]

parent_commit = s.pull_state.commits[1]["parents"][1]["sha"]

error fetching checks

Hangs on Fetching checks and then notifies with failed to fetch remote branch

Neovim version -

v0.8.0-dev+160-gdbdd58e54

Config-

 use({
            'ldelossa/gh.nvim',
            event = 'InsertEnter',
            requires = 'ldelossa/litee.nvim',
            config = function()
                require('litee.lib').setup()
                require('litee.gh').setup()
            end
        })

Expected Outcome -

The remote branch should have been fetched and the PRs to be seen

Message on startup

Hi. I like your project and believe I will be using it. However, after a relatively recent update, gh.nvim will echo "[gh.nvim] started background refresh with interval 3 minutes" when I start neovim. It does not seem useful and at the very least, it seems out of place in this context. I suggest either of the following actions:

  • Remove this message in general.
  • Do not show message on neovim start, but rather whenever any gh.nvim related contexts is opened.
  • Any of the above with an option to control the behaviour.

Also: The background refresh is not explained in the docs and it is unclear what it is.

Trying to open a PR throws error

Not sure, but I think the plugin got stuck on fetching contributors (⣷ fetching repository contributors). It's my company's private repo, so maybe it times out because of too many contributors.
The error I get is:

Error executing luv callback:
...te/pack/packer/start/gh.nvim/lua/litee/gh/ghcli/init.lua:68: Expected the end but found T_ARR_BEGIN at character 100610
stack traceback:
        [C]: in function 'decode'
        ...te/pack/packer/start/gh.nvim/lua/litee/gh/ghcli/init.lua:68: in function <...te/pack/packer/start/gh.nvim/lua/litee/gh/ghcli/init.lua:59>

Failed to submit review

Hi,
Thanks for the great plugin!

I have a problem, I always get Failed to submit review when doing :GHSubmitReview. I also cannot do :GHCreateThread if review is pending. Because I getFailed to create new comment after writing something then.

Is this something trivial I am missing? I can do :GHCreateThread outside of PR review still.

Diffview diffs file incorrectly when thread is displayed

When a thread is displayed in the diffview and you attempt to open another file in the diffview, the diff itself is displayed incorrectly. It appears the same diff is seen on both sides (tho not collapsed like a normal diff of the same file contents would do).

This is avoided by opening the file in the diffview again.

Hide gutter icon?

Hey - thank you for this awesome plugin!

How do you hide the gutter icon?

image

Getting "Error fetching repo, json decoding error" when running running `GHOpenPR` from a private repo

On neovim 0.7 release, the PR list opens with a few PRs but when I select one it appears to fail somewhere in the process. Is there a way to enable more logging, in case that would help?

"Error fetching repo, json decoding error"

Also, when I selected a PR later:
"A pull request is already opened, close it and open pull #685?" and say "yes", I the error below:

E5108: Error executing lua ...ll/.config/nvim/plugged/gh.nvim/lua/litee/gh/pr/init.lua:363: attempt to index field 'state' (a nil value)
stack traceback:
        ...ll/.config/nvim/plugged/gh.nvim/lua/litee/gh/pr/init.lua:363: in function 'close_pull'
        ...ll/.config/nvim/plugged/gh.nvim/lua/litee/gh/pr/init.lua:213: in function 'on_choice'
        ...e-ui-select.nvim/lua/telescope/_extensions/ui-select.lua:122: in function 'run_replace_or_original'
        ...nvim/plugged/telescope.nvim/lua/telescope/actions/mt.lua:65: in function 'key_func'
        ...g/nvim/plugged/telescope.nvim/lua/telescope/mappings.lua:242: in function 'execute_keymap'
        [string ":lua"]:1: in main chunk

Not sure if the last one was related to already being on the PR branch or not.

From this reddit thread

GHClosePR has Invalid Window

Running GHOpenPR, selecting a PR, then immediately running GHClosePR results in this error:
Screen Shot 2022-08-10 at 6 27 38 AM

I just updated GH yesterday so I should be on the newest.

Also might be a good idea to state that GHClosePR closes neovims instance of a PR, not the original PR. Made me hesitate to call it.

Doesn't work with nvim-tree

When nvim-tree is enabled, most things don't work. For example, opening a diff in "Files Changed" causes the diff buffer to appear for a moment and then disappear.

Issue with multi-root workspace folders (golang)

In some cases when opening a PR and then trying to open a file for a diff, it can't find it because the path is wrong.

Let's say the path is this/my/pkg and I try to open the file this/my/pkg/subpkg/file.go I'll get an error that the file can't be found by gopls LSP[gopls] Error loading workspace folders (expected 1, got 0) failed to load view for file:///Users/projects/this/my/pkg/subpkg/my/pkg/subpkg/: invalid workspace folder path: no such file or directory

So it seems like it's adding the whole path to the path again. I'm not sure where and why this happens but when I just open the file the normal way, everything works fine.

I'm not entirely sure what the problem is but the repo has multiple workspace roots, so if I check vim.lsp.buf.list_workspace_folders() I get {"this/", "this/my/pkg/"}. My guess now is that instead of using the first one ("this/") and adding the file path to it, the second one is used to add the whole path.

Maybe something like local workfolder = vim.lsp.buf.list_workspace_folders()[1] or vfn.getcwd() when determining the path might help.

Slow Startup

With gh.nvim disabled, --startuptime is showing neovim takes about 80ms to initialize with the plugins I have active. Once I enable gh.nvim, this number jumps to about 600ms. I initially thought that some of this load time was due to the scheduling of the print statement when gh.nvim launches, but after commenting it out that only cut the load time down to about 450ms. The only solution that keeps my startup time to <100ms is to configure gh.nvim in the following way:

return require('packer').startup(function()
        ...
	use {
		'ldelossa/gh.nvim',
		requires = { { 'ldelossa/litee.nvim' } },
	}
	...
end)

function SetupGithub()
	require('litee.lib').setup()
	require('litee.gh').setup({
	  ...
	})
end
vim.schedule(SetupGithub)

I have not done any deeper profiling of gh.nvim to determine where the latency is coming from, but given my "solution" I suspect it has due to do with initializing litee.

More Robust Error Handling

I've had a few issues this morning using the plugin. I'm happy to help debug, but I'm not sure exactly where I can find more information about the errors. Specifically, I've had the following happen to me:

  1. Sometimes I can not even open a PR right after starting nvim - I get failed to fetch remote branch in what appears to be the 'fetching checks' stage.
  2. When trying to open a PR while one is already open, I enter 'yes' and get the following error:
E5108: Error executing lua .../site/pack/packer/start/gh.nvim/lua/litee/gh/pr/init.lua:365: attempt to index field 'state' (a nil value)
stack traceback:
      .../site/pack/packer/start/gh.nvim/lua/litee/gh/pr/init.lua:365: in function 'close_pull'
      .../site/pack/packer/start/gh.nvim/lua/litee/gh/pr/init.lua:216: in function 'callback'
      ...er/start/dressing.nvim/lua/dressing/select/telescope.lua:58: in function 'run_replace_or_original'
      ...packer/start/telescope.nvim/lua/telescope/actions/mt.lua:65: in function 'key_func'
      ...k/packer/start/telescope.nvim/lua/telescope/mappings.lua:242: in function 'execute_keymap'
      [string ":lua"]:1: in main chunk
  1. I also get the following error when trying to explicitly close an open PR:
Error executing Lua callback: .../site/pack/packer/start/gh.nvim/lua/litee/gh/pr/init.lua:365: attempt to index field 'state' (a nil value)
stack traceback:
        .../site/pack/packer/start/gh.nvim/lua/litee/gh/pr/init.lua:365: in function <.../site/pack/packer/start/gh.nvim/lua/litee/gh/pr/init.lua:344>

FzfLua register_ui_select opens second prompt in NORMAL mode

When I run GHSubmitReview, the FzfLua popup asks me if I want to approve, comment, etc...
When I select approve a new popup asks if I want to add a comment or not.
But I can not select any option because I am in NORMAL mode, and not TERMINAL mode as in the previous popup.

I know that this issue may not be strictly related to gh.nvim. But maybe you also had this issue.

My fzf-lua config, if it helps.

Comments appear on the wrong lines

Whenever I call GHCreateThread on a particular line, comment appears in a different line.
It happens mostly after GHStartReview. If I add comment w/o starting a review, comments appear on the right positions.

I saw this thread #66. It looks similar but I didn't get what was the solution for the issue.

How to reproduce:

  1. git worktree add ../review_dir
  2. cd ../review_dir
  3. nvim
  4. GHOpenPR. PR contains several commits.
  5. GHStartReview
  6. Go to any commit (the last one, for instance) and try to add a comment. GHCreateThread

Expected result:

  1. Comment appears on the right position

Actual result:

  1. Comment appears on a completely different line

Note: if I don't start review, comment most likely appears on the right position.

Env:
nvim v0.8.0
gh.nvim latest
macos latest
iterm2 latest

Support requesting code suggestions

Hey!

First of all, loving the look of this plugin - I'm actively watching its development. Haven't used it yet as I'll be waiting for the all commits flag; which is more inline with my workflow.

I was wondering if you support / have plans on supporting requesting code suggestions? One of the biggest frustration points for me when reviewing PR's is not having LSP + treesitter support in the GitHub UI, resulting in requested changes with typo's + indentation issues etc. Would love to get your thoughts on this!

Thanks :)

feat: Find PR from older than the latest 100

https://github.com/cilium/cilium/pulls can get a bit unruly over time, at the moment ~180 PRs. Since litee's M.list_pulls() is limited to listing the most recent 100 PRs, this can mean that the PR I'm looking for doesn't show up in the popup when I run GHOpenPR.

Looks like a few workarounds are available: manually bump the 100 PR limit, use GHOpenPR <number> to open the target PR, or do some gardening of the set of open PRs in the project...

Probably for bigger projects this could come up more often. I wonder if there's a way to support search here better, either through some form of pagination / pulling the next 100 or a direct search function.

Getting error open GHOpenPR on litee/gh.nvim latest

I'm getting this error and am not sure what might cause it. I use the default setup() and tried to set the icon_set options to nil or "" but that didn't help:

Error executing vim.schedule lua callback: ...ker/start/litee.nvim/lua/litee/lib/tree/marshal/init.lua:66: attempt to index upvalue 'icon_set'
 (a nil value)
stack traceback:
        ...ker/start/litee.nvim/lua/litee/lib/tree/marshal/init.lua:66: in function 'marshal_node'
        ...ker/start/litee.nvim/lua/litee/lib/tree/marshal/init.lua:153: in function '_marshal_tree'
        ...pack/packer/start/litee.nvim/lua/litee/lib/tree/init.lua:306: in function 'write_tree'
        ...pack/packer/start/litee.nvim/lua/litee/lib/tree/init.lua:315: in function 'write_tree_no_guide_leaf'
        ...vim/site/pack/packer/start/gh.nvim/lua/litee/gh/init.lua:53: in function 'pre'
        ...ack/packer/start/litee.nvim/lua/litee/lib/panel/init.lua:129: in function 'toggle_panel'
        ...e/pack/packer/start/gh.nvim/lua/litee/gh/pr/handlers.lua:154: in function 'ui_handler'
        ...e/pack/packer/start/gh.nvim/lua/litee/gh/pr/handlers.lua:179: in function ''
        vim/_editor.lua: in function <vim/_editor.lua:0>

Creating a thread does not survive a refresh

When creating a thread and typing some text if a background refresh occurs, sometimes you loose all the text. This does not happen on other convo buffers due to some careful programming. re-implement that into the create comment refresh

Cycle Through Files in Commit

A nice quality of life feature (for me) would be the ability to cycle through files in a commit (or in the PR overall, if a specific commit is not open). Then I could close the Lite Panel on the side and use a shortcut to cycle through the files per commit. Something like GHCommitNextFile, GHCommitPrevFile, GHPRNextFile, GHPRPrevFile - or just GHNextFile and GHPrevFile which calculate the next/prev file based on whether a specific commit is selected or not.

On refresh, check panel presence

When doing a PR refresh, the panel is toggled open unconditionally.

Instead, check to see if the panel was open or closed before and only open it if it was.

Support for autochdir option

I noticed that gh.nvim does not work well with set autochdir. Here's a minimal test:

  • Create a PR in some test repo with some changes.
  • Create test.vim as under.
  • Go to the local path for test repo.
  • nvim --clean -u test.vim
  • :GHOpenPR - open the PR.
  • Open a diff for a modified file, then :GHCreateThread.
  • Add comment, then do <c-s>.

Expected: Comment is added and the UI is refreshed.

Observed: Following error message and no refresh of UI.

image

test.vim

set nocompatible
set runtimepath^=~/.local/plugged/gh.nvim
set runtimepath^=~/.local/plugged/litee.nvim
filetype plugin indent on
syntax enable

set autochdir

lua <<EOF
require('litee.lib').setup()
require('litee.gh').setup()
EOF

error handling for non-github repos

Great project. Thank you. Looking forward to using this tool.

I noticed that the erroring around non-github repos doesn't provide much help. It might seem obvious that PR's are not a feature of git but rather of github, but it's easy to forget or simply not know where git and gh differ.

proposal

A clearer error set of error messages when the repo is not hosted by github would be welcome.

Happy to take this on if you are accepting contributors. Cheers and thanks again.

Support for Enterprise GitHub

Hi 👋 ,

I was trying to use this plugin with our internal Enterprise GitHub server (not github.com).

When running :GHOpenPR I successfully retrieve a list of pull requests, but when selecting one I get

Failed to fetch pull request: Not Found

Are Enterprise GitHub servers supported?

Thanks a lot and best regards,
David

gh version 2.10.1 (2022-05-10)

Nothing happens after trying to open PR

hi!

Trying to open PR using :GHOpenPR in nvim and it this little thing opens at the bottom of my editor asking which PR i want to open.

After which; it says it's fetching and all that suff but it always has a red errror at the top right indicating error adding remote

Ive tried this for a couple of hours and sometimes i get the diff windows; and sometimes I don't. For the times the diff windows worked; my git status always returns the commit ID of the current 'branch' its checked out on.

On the other hand; if it does nothing, my git status always shows the current branch i.e. master.

Is there anything I can do to help you debug this?

[request] Wiki Editing

Would be super cool to edit GitHub wikies from inside nvim. If a given repo has a wiki, some :GHWiki or some such could open a wiki editor

Splat when GHToggleThreads is run against a hunk with no thread / comments

I tried to use GHToggleThreads on a hunk I was viewing, without realizing that there are no existing comments / threads. Here's the splat:

Error executing Lua callback: /home/joe/.vim/bundle/gh.nvim/lua/litee/gh/pr/diff_view.lua:526: attempt to index field 'threads_by_line' (a nil value)                                                                                                                                       
stack traceback:                                                                                                                                                                                                                                                                            
        /home/joe/.vim/bundle/gh.nvim/lua/litee/gh/pr/diff_view.lua:526: in function 'toggle_threads'                                                                                                                                                                                       
        /home/joe/.vim/bundle/gh.nvim/lua/litee/gh/commands.lua:45: in function </home/joe/.vim/bundle/gh.nvim/lua/litee/gh/commands.lua:45> 

Create threads on current checked out commit

When using the commit view browser, the commit is checked out locally.

However, when you create a thread the thread is created on the latest commit regardless. This means you can be creating a commit on a line which has since been updated.

Instead, when creating a thread, determine the commit that is currently checked out, and always create the thread at this commit. It will appropraitely show you if the comment you just created is outdated during review and you can choose not to submit that message.

Make omnicomplete a high level feature

Currently, omnicomplete functions populate collaborator and issue data for completion only on PR load.

Now that GitHub Issues are an independent feature, and we want completion there too, we must make the sourcing of completion information a high level feature, yoinked out of the PR module.

Consider using completion in Git related buffers as well. For example if Neovim is being used on "git commit -s" it would also be nice to have completion info for the repository available. Allowing @username and #issue completion in commit messages.

UI/Rendering Questions

Figured I would just use this thread to ask my questions instead of create separate issues.

You'll notice that in the image below there are three things happening:

  1. The main panel doesn't have the same type of comment separation that your introduction video has. In that video it seems like you have smooth lines, and I enjoy that look.
  2. On the right, you'll see that I have these dotted lines, which offers a poor aesthetic.
  3. On the right, you'll see that the icons don't show up that nicely (though some do).

I'm trying to figure out what the UI issue could be here, but ideally i'd love to get a similar look/feel to how you have it in your introductory video and I think there might be a config i'm missing because I should be able to support a similar look with my setup.

I have also included my terminal set up and things that might be relevant below so that you can see what I am working with.

Screenshot 2023-04-05 at 5 29 36 PM

My terminal setup that could be relevant:

  • Using iTerm2
  • MesloLGLDZ Nerd Font Mono (Supports Ligatures).

Current gh.nvim config:

use({
    "ldelossa/gh.nvim",
    requires = { { "ldelossa/litee.nvim" }, { "kyazdani42/nvim-web-devicons", opt = true } },
})
require("litee.lib").setup({
	tree = {
		icon_set = "nerd",
	},
	panel = {
		orientation = "right",
		panel_size = 30,
	},
})
-- this is where you configure details about your panel, such as
-- whether it toggles on the left, right, top, or bottom.
-- leaving this blank will use the defaults.
-- reminder: gh.nvim uses litee.lib to implement core portions of its UI.

require("litee.gh").setup({
	-- this is where you configure details about gh.nvim directly relating
	-- to GitHub integration.
	-- deprecated, around for compatability for now.
	jump_mode = "invoking",
	-- remap the arrow keys to resize any litee.nvim windows.
	map_resize_keys = false,
	-- do not map any keys inside any gh.nvim buffers.
	disable_keymaps = false,
	-- the icon set to use.
	icon_set = "default",
	-- any custom icons to use.
	icon_set_custom = nil,
	-- whether to register the @username and #issue_number omnifunc completion
	-- in buffers which start with .git/
	git_buffer_completion = true,
	-- defines keymaps in gh.nvim buffers.
	keymaps = {
		-- when inside a gh.nvim panel, this key will open a node if it has
		-- any futher functionality. for example, hitting <CR> on a commit node
		-- will open the commit's changed files in a new gh.nvim panel.
		open = "<CR>",
		-- when inside a gh.nvim panel, expand a collapsed node
		expand = "zo",
		-- when inside a gh.nvim panel, collpased and expanded node
		collapse = "zc",
		-- when cursor is over a "#1234" formatted issue or PR, open its details
		-- and comments in a new tab.
		goto_issue = "gd",
		-- show any details about a node, typically, this reveals commit messages
		-- and submitted review bodys.
		details = "d",
		-- inside a convo buffer, submit a comment
		submit_comment = "<C-s>",
		-- inside a convo buffer, when your cursor is ontop of a comment, open
		-- up a set of actions that can be performed.
		actions = "<C-a>",
		-- inside a thread convo buffer, resolve the thread.
		resolve_thread = "<C-r>",
		-- inside a gh.nvim panel, if possible, open the node's web URL in your
		-- browser. useful particularily for digging into external failed CI
		-- checks.
		goto_web = "gx",
	},
})

Nerd font not working

I'm using FiraCode with Alacritty (terminal emulator) in tmux and the icons don't display properly.
image

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.