Changing git executable variable

[nlinaje]

I hope this is the correct place to put my question. I am sorry if it is not.
To manage my dotfiles, I am using a bare repository as explained here.

That way, I have an alias to deal with my dotfiles with git:
alias dotfiles='/usr/bin/git --git-dir=$HOME/.cfg/ --work-tree=$HOME'

When I try to use vim-fugitive with my dotfiles project, I receive the failure "fugitive: file does not belong to a Git repository".
Of course, this failure makes sense, as it can not found the ".git" directory.

I tried changing the global fugitive git executable variable manually in vim:

:let g:fugitive_git_executable = 'dotfiles'
but :Gstatus continues bringing the failure.

My next step was to try it manually:
:!dotfiles status
which brings the failure: command not found :)

I used this answer here to allow using aliases in vim. But although it works manually (:dotfiles status), setting the g:fugitive_git_executable variable to 'dotfiles' does still not work.

Any ideas what I am doing wrong? How can I use vim-fugitive to manage my dotfiles?
Many thx in advance! Your plugins are really awesome :)

[tpope]

Fugitive is transitioning away from using the shell and towards invoking the git executable directly. A shell alias won't work. You can get over this particular hurdle with a wrapper script but doubtless there are more ahead. Fugitive does not expect g:fugitive_git_executable to provide its own Git dir and you'll probably just end up confusing it.

My preferred solution would be to make this work:

:Git --git-dir=$HOME/.cfg --work-tree=$HOME

I haven't implemented this because I haven't managed to decipher how --git-dir= and --work-tree= interact with -C and the current working directory, as we rely on those to implement much of Fugitive's functionality.

[mikehaertl]

@tpope Did you give this another thought? I'd also find it awesome if fugitive could support bare repos.

I'm probably simplifying this too much, but I had a rough idea like this in mind:

Assuming that there is already some repo detection logic implemented (e.g. find .git dir or similar), it could stay the same and have highest priority.

But if no git repo was detected then it could check the keys of a user defined dictionary like:

let g:fugitive_bare_repos = {
      \ '/path/to/workdirA': '/path/to/bare/repoA',
      \ '/path/to/workdirB': '/path/to/bare/repoB'}

If the current buffer file is in or below any of the workdir directories then it should add the --work-tree=<key> --git-dir=<value> options and just leave out the -C.

Because as I see it -C and the --git-dir/--work-tree options are kind of complementary. From the man page:

-C
Run as if git was started in instead of the current working directory. When multiple -C options are given, each subsequent non-absolute -C is interpreted relative to the preceding
-C . If is present but empty, e.g. -C "", then the current working directory is left unchanged.

This option affects options that expect path name like --git-dir and --work-tree in that their interpretations of the path names would be made relative to the working directory caused by the -C
option. For example the following invocations are equivalent:

  git --git-dir=a.git --work-tree=b -C c status
  git --git-dir=c/a.git --work-tree=c/b status

[mikehaertl]

I should have done more research first: Seems like this is already adressed in #1796 and #1841. The suggested solution with FugitiveDetect() also leaves enough room to implement a similar logic as above in my own config. Thanks!

[tpope]

You've got your answer, but to clear some things up:

@tpope Did you give this another thought? I'd also find it awesome if fugitive could support bare repos.

Fugitive has extensive support for bare repos. You can access the full history of a bare repository without having a work tree at all! What you're asking for is closer to "take this random directory and pretend it's a work tree linked to this bare repository".

I'm probably simplifying this too much, but I had a rough idea like this in mind:

Assuming that there is already some repo detection logic implemented (e.g. find .git dir or similar), it could stay the same and have highest priority.

But if no git repo was detected then it could check the keys of a user defined dictionary like:

let g:fugitive_bare_repos = {
      \ '/path/to/workdirA': '/path/to/bare/repoA',
      \ '/path/to/workdirB': '/path/to/bare/repoB'}

It follow from the above that g:fugitive_bare_repos is a bad name. I'm not even sure what a good name would be.

If the current buffer file is in or below any of the workdir directories then it should add the --work-tree=<key> --git-dir=<value> options and just leave out the -C.

With git, there's no configuration for this, you have to pass --work-tree and --git-dir yourself. I don't think :Git should be any different.

Because as I see it -C and the --git-dir/--work-tree options are kind of complementary. From the man page:

-C
Run as if git was started in instead of the current working directory. When multiple -C options are given, each subsequent non-absolute -C is interpreted relative to the preceding
-C . If is present but empty, e.g. -C "", then the current working directory is left unchanged.
This option affects options that expect path name like --git-dir and --work-tree in that their interpretations of the path names would be made relative to the working directory caused by the -C
option. For example the following invocations are equivalent:

  git --git-dir=a.git --work-tree=b -C c status
  git --git-dir=c/a.git --work-tree=c/b status

Okay, so how do you stage a file? git --git-dir=c/a.git --work-tree=c/b add c/b/README? Think again. The interaction between is far more nuanced and quirky than the man page would suggest. And that's the short answer to why :Git doesn't currently support these options.

[mikehaertl]

Okay, so how do you stage a file? git --git-dir=c/a.git --work-tree=c/b add c/b/README? Think again. The interaction between is far more nuanced and quirky than the man page would suggest. And that's the short answer to why :Git doesn't currently support these options.

Ok, as we have an alternative in FugitiveDetect() that's totally fine.

For the record here's the setup I use now, which seems to do the trick for me. But maybe I've missed some potential pitfalls. So feedback welcome:

cd ~
git init --bare .dotfiles
git --git-dir=/home/mike/.dotfiles config --unset core.bare
git --git-dir=/home/mike/.dotfiles config --add core.worktree /home/mike
git --git-dir=/home/mike/.dotfiles config --add status.showUntrackedFiles no

and in vimrc:

augroup dotfiles
  autocmd VimEnter * call InitDotfileRepo()
  autocmd BufReadPost * call InitDotfileRepo(bufnr(''))
augroup END

function InitDotfileRepo(...)
  " Could be global config or a dictionary
  let dotfile_dir = '/home/mike'
  let dotfile_repo = '/home/mike/.dotfilerepo'

  " Did fugitive detect a git repo? Then do nothing
  if (len(FugitiveGitDir()))
    return
  endif

  " Else check if we are in the dotfile worktree
  let path = fnamemodify(a:0 ? bufname(a:1) : getcwd(), ':p:h')
  let dotfile_len = len(dotfile_dir)
  if (len(path) >= dotfile_len && path[0:dotfile_len - 1] ==# dotfile_dir)
    call FugitiveDetect(dotfile_repo)
  endif
endfunction