Feature Request: Gstatus on empty buffer

[amadeus]

Not sure if this has been discussed before, however It would be rad if :Gstatus could work on empty buffer by inheriting the cwd, especially now that a DirChanged autocmd has been added to Vim since it could update from that event as well.

[tpope]

Hasn't been discussed since DirChanged, but I'm unpersuaded. What happens if I chdir out of a repository? Am I supposed to manually delete all the commands one by one?

[amadeus]

Sorry for the delayed response to this.

It may be tough to convince senpai, however I do think that :Gstatus should just be a command available anytime from anywhere, which would mean you actually would never have a need to clean it up. Within a CLI, if I you try to git status on a directory that isn't within git, you simply get the output fatal: Not a git repository (or any of the parent directories): .git.

I think it would be pretty useful if you could execute :Gstatus from anywhere - if it's from a buffer with a file, then it uses that file's git repo - if there is none, it attempts to fallback to the working directory, if that still fails, it could either a) open that split with the fatal error message above, or just echo it to the cmd area. And if the buffer is not a file at all, it just attempts to use the current working directory with a similar output if it's a valid git directory or not.

[tpope]

The difference is that Git provides one command everywhere, whereas Fugitive provides 30ish. I could see doing that for a general purpose SCM plugin, but one SCM just seems like a bridge too far.

Remind me why this is such a big deal? I've begrudgingly covered the VimEnter case. Is it just about being able to press Cmd-T in MacVim?

[amadeus]

My usual workflow using MacVim, is that I generally use a window per project. Often times I will open up a MacVim window, cd into the directory of my project, and want to just do a quick :Gstatus to pull up where I am at. Currently I have to open up a file from the project before I can do this.

The sort of inverse will also happen sometimes, I'll close out all open buffers from some work I am doing, but then want to call :Gstatus to monitor git things, but then need to re-open a file.

It's not a huge deal, but I do love the functionality of :Gstatus and often like to use it as a hub for what I am working on.

[tpope]

If :Gstatus from the project root is all you care about, you can just wrap up :pedit .git/index in whatever way suites you. There's just a few small differences between that and :Gstatus (which could be eliminated if need be).

[amadeus]

Oh interesting, I could probably hack around it then, didn't realize it did so little by default

[Cimbali]

A pair of use cases for illustration.

- When doing `:Gstatus` and going over what needs staging etc, the file open in the current tab gets replaced as soon as I start looking at diffs. As I use more tabs than buffer lists, I'd like to open a new tab before doing that, and have that tab be aware of the repo I'm in (currently working around with `:tabe %`) - I often `Ggrep` or `:tj` (with tags in .git/tags) in big projects where I don't know which file I want to open yet, so then I open vim in a repo (*) to search in that repo and get the results inside vim (currently working around by opening a random file `:e ` after `:cd`). (*) or open vim then `:cd` to the repo, or even open a new tab while I'm in one project, `:lcd` to another project on which the first one depends. - Maybe this'll also allow to do some inspection of bare repos from within vim in the future?

Another workaround is to do bind FugitiveDetect(getcwd()) to some key and do it manually.

Now one thing is that I'm not sure what events can be used for :sp or :tabe if there is no changing directories, I could only find BufWinEnter even though that does get triggered a lot more.

About cleaning up the commands, I don't know if that's really necessary. They don't really "pollute" the command space, as:

• calling them outside of a repo already fails cleanly with an error message fatal: not a git repository for most commands (a few have that message as an uncaught exception)
• they're local to just one buffer
• nobody will define commands that clash fugitive commands as they have the plugin installed
• empty buffers don't stay empty that long.

If you still want to clean it up, it's not too hard to do as all commands are already contained in s:commands so a small loop would do the trick.

[tpope]

First, in closely related news, I must report that I have decided :Gstatus is bad. It's basically a project drawer, which means it's terrible for window management, and the whole open in a new tab thing is a symptom of that. See #569 for discussion about replacing it.

In lieu of :cd or :lcd, I recommend using :e to invoke netrw, then press c to change directory. It's the same number of characters, and it exchanges the worthless garbage that is an unnamed buffer for a bit of visual context and an additional option for browsing.

Tangentially, note that I am now discouraging the use of .git/tags and might even take it away in the next major release. I have decided the elegance of avoiding a .gitignore entry is negated by the unfortunate asymmetry between Git projects and non-Git projects, and it lacks the flexibility to accommodate some use cases I have come to care about (like multiple tag files for multiple languages).

[tpope]

Experimental support is on mater. I may yank it if it turns out to be too confusing or non-performant.

I have not yet made global commands for subcommands that are also available on :Git, for example :Git commit.

[amadeus]

I have been loving this new support of :G from basically anywhere, so much appreciated!

[still-dreaming-1]

I'm confused. This started out as a conversation about updating what fugitive considers to be the current working directory by tying into the DirChanged autocmd and then ended up discussing the new :Git as an improvement upon :Gstatus. But as far as I can tell, it doesn't eliminate the need for using the autocmd.

[tpope]

I'm confused. This started out as a conversation about updating what fugitive considers to be the current working directory by tying into the DirChanged autocmd and then ended up discussing the new :Git as an improvement upon :Gstatus.

So called discussion is in fact a 3 sentence aside that starts with "in closely related news".

But as far as I can tell, it doesn't eliminate the need for using the autocmd.

No, but the commit that closed this issue did.

[still-dreaming-1]

the commit that closed this issue did.

Ah, I see that now. Nice work resolving the issue.

[detailedghost]

For anyone digging on how to make Git fugitive open in a new tab, I added the following keymap that works pretty well:

:G <CR><C-W>T<CR>

[tpope]

You can use :tab G<CR> to accomplish that without risk of resizing windows in the current tab.