Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

git_files shows submodules #410

Closed
qbedard opened this issue Jan 10, 2021 · 12 comments
Closed

git_files shows submodules #410

qbedard opened this issue Jan 10, 2021 · 12 comments
Assignees

Comments

@qbedard
Copy link

qbedard commented Jan 10, 2021

Description

The git_files picker shows git submodules. This is both annoying and can break previewers that are expecting to act only on files, such as the new vim_buffer_cat previewer.

I haven't found a suitable option for git ls-files or an alternative single command that gives us what we want, so we might just need to filter out the submodules from the list. From cursory exploration, it looks like we can use the output of git submodule status or just parse .gitmodules to determine what the submodules for the repo are.

Alternatively, git grep --exclude-standard --cached --untracked -l "" comes really close, but excludes empty files and symlinks as well.

Expected Behavior
The git_files picker does not show git submodules.

Actual Behavior
The git_files picker shows git submodules.

Details

Reproduce
  1. Open nvim in a git repo with one or more submodules.
  2. :Telescope git_files
Environment
  • nvim version: v0.5.0-dev+b535575ac
  • Operating system: macOS
  • Telescope commit: de80a98
Configuration

(default)

set nocompatible hidden laststatus=2

if !filereadable('/tmp/plug.vim')
  silent !curl --insecure -fLo /tmp/plug.vim
    \ https://raw.githubusercontent.com/junegunn/vim-plug/master/plug.vim
endif

source /tmp/plug.vim
call plug#begin('/tmp/plugged')
Plug 'nvim-lua/popup.nvim'
Plug 'nvim-lua/plenary.nvim'
Plug 'nvim-telescope/telescope.nvim'
call plug#end()

autocmd VimEnter * PlugClean! | PlugUpdate --sync | close
lua << EOF

require('telescope').setup{
  defaults = {
    vimgrep_arguments = {
      'rg',
      '--color=never',
      '--no-heading',
      '--with-filename',
      '--line-number',
      '--column',
      '--smart-case'
    },
    prompt_position = "bottom", 
    prompt_prefix = ">",
    selection_strategy = "reset",
    sorting_strategy = "descending",
    layout_strategy = "horizontal",
    layout_defaults = {},
    file_ignore_patterns = {},
    shorten_path = true,
    winblend = 0,
    width = 0.75,
    preview_cutoff = 120,
    results_height = 1,
    results_width = 0.8,
    border = {},
    borderchars = { '', '', '', '', '', '', '', ''},
    color_devicons = true,
    use_less = true,
  }
}
EOF
@Conni2461 Conni2461 self-assigned this Jan 10, 2021
@Conni2461
Copy link
Member

Conni2461 commented Jan 10, 2021

Okay i see what you are saying. The bug, why its crashing, is in plenary so i messed up something there :|

There is a PR #329 which allows you to display submodules content but thats not what you expect so i was planing to do a ls for vim_buffer_cat, currently we have that in term_previewers but not for the new once. I was talking about it here #395 (comment).

The easy way would be to just run ls but i think we can do this just with vim.loop.fs_ and i am really close to finishing it nvim-lua/plenary.nvim#45.

Maybe that will help in the future because i am not sure if we can realize that submodules are not shown at all.

Edit: Fix for the crash is here nvim-lua/plenary.nvim#47. CI is currently broken because we can't find a nightly image. Vanished again :|

@qbedard
Copy link
Author

qbedard commented Jan 10, 2021

Ah, word. I searched issues, but I guess I forgot to search PRs. Looks like you've got adherence to gitignore in there too. Kudos.

Bummer about the CI.

@Conni2461
Copy link
Member

No worries. Still grateful about the issue. Didn't know that directory was crashing again.

CI comes back :) just need a nvim nightly image on github to pull.

The original plan with my PR was to have a fd replacement written in lua and respect_gitignore was only directed for that.
The ls replacement was not meant to have respect_gitignore but because its based on the fd replacement now, just with depth = 1 and long format, its possible to enable that feature. We probably wont for the buffer_previewer but you could just replace the previewer_file_maker and enable that opt. But that Music of the future.

I am planing to finish that directory previewer over the next week. I just pushed a first draft and updated the PR description with a preview of the output. Hardest part is converting the uid / gid to the actual name without leaving lua land and running id -nu.
And i have to test on a windows machine 😆

@qbedard
Copy link
Author

qbedard commented Jan 11, 2021

Roger that.

For the time being (and for anyone else who runs across this), I'm able to get what I want (git repo files sans submodules with the new buffer preview) easily enough by writing a quick project files picker function that just uses the regular find_files from the git root:

local M = {}
...
M.project_files = function()
  require("telescope.builtin").find_files {
    cwd = require("lspconfig.util").root_pattern(".git")(vim.fn.expand("%:p"))
  }
end

I just used root_pattern() from nvim-lspconfig for simplicity. I actually don't mind gitignore'd files much, though I might try and whip up a mapping to toggle hidden files.

The bee's knees would probably be:

  • git repo files
  • ignore submodules entirely
  • toggle for gitignore
  • toggle for hidden
  • fallback to current dir files if no project found

@Conni2461
Copy link
Member

Okay i think we are done with this now. We can list submodules and show dirs in the buffer previewer.
If you still wanna pass different opts to ls_async tell me and i can tell you how to do so.
If you have any issues feel free to reach out to me.

About your point of fallback to find_files if no git repo you can write that function:

M.project_files = function()
  local opts = {} -- define here if you want to define something
  local ok = pcall(require'telescope.builtin'.git_files, opts)
  if not ok then
    require'telescope.builtin'.find_files(opts)
  end
end

Thanks for reporting and your insight :)

Closing for now. Feel free to reopen if anything is left :)

@qbedard
Copy link
Author

qbedard commented Jan 23, 2021

Hmmm. After updating, I'm actually getting this for git_files when it tries to preview the submodule dir:

Error executing luv callback:                                                                                                                                                                          
...e/pack/packer/start/plenary.nvim/lua/plenary/scandir.lua:239: table index is nil

@Conni2461
Copy link
Member

nvim-lua/plenary.nvim#55

Should at least fix it but there is another issue. You are on a mac right? Accordning to google i can't read passwd for the usernames and ids :| So i can go from id to name. Didn't know about that 😆

I do some more digging later today. Sorry for the inconvenience :)

@Conni2461 Conni2461 reopened this Jan 23, 2021
@Conni2461
Copy link
Member

I doing another confident close here. Hopefully that doesn't jinx it 😆

Thanks for the testing @timbedard :)

@qbedard
Copy link
Author

qbedard commented Jan 24, 2021

Thanks for the good work! 😁

@motorto
Copy link

motorto commented Oct 1, 2022

The fallback to find_files if no git repo is found seems to no longer work:

			project_files = function()
				local opts = {} -- define here if you want to define something
				local ok = pcall(require "telescope.builtin".git_files, opts)
				if not ok then require "telescope.builtin".find_files(opts) end
			end

			local Opts = { noremap = true, silent = true }

			vim.api.nvim_set_keymap('n', '<leader>ff', '<cmd>lua project_files()<cr>', Opts)

image

@bangedorrunt
Copy link

bangedorrunt commented Oct 1, 2022

@motorto @Conni2461 See #2183

@motorto
Copy link

motorto commented Oct 2, 2022

@bangedorrunt Thanks the workaround indeed works, update the recipe on the wiki so that no one stumbles on this again would be appreciated

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants