On Windows, if Vim is invoked with a working directory starting with a
lowercase drive letter (e.g. c:\<path> instead of C:\<path>), some
mappings in the blame buffer do not work correctly. For example,
hitting Enter on a line throws an exception rather than showing the
associated commit. The reason for this is that the b:git_dir variable
is not being set on the blame buffer. The reason in turn for this is
that the path to the blame buffer is being stored in s:temp_files with
an uppercase drive letter, but in the fugitive_temp augroup, '<afile>:p'
is being expanded with a lowercase drive letter, so the lookup in
s:temp_files fails. Fix this by converting paths to lowercase before
using them as keys for the s:tempfile dictionary. Because of the way
Vim generates temporary file names, this is safe even on platforms with
case-sensitive file systems.
Our doautocmd in s:ReplaceCmd already processes the modelines while the
buffer is still modifiable, so we can disable it after tha prevent
subsequent invocations.
Closes#323.
This reverts commit d6540b2588, which
caused all sorts of breakages with buffer names with brackets in them.
This was greatly exacerbated by airline.vim setting an erroneous
b:git_dir in plugin buffers based on the current working directory.
Closes#464. Closes#463. Closes#461.
There are rare situations where a user has manually specified what they
wish to use as their work-tree directory, and even rarer situations
where the user wishes the Git directory to be customized. In the case
the user has set these using environment variables, vim-fugitive takes
advantage of these settings in order to set up.
Note that git-config(1) allows setting the work-tree and Git dir in
a number of ways (see the core.worktree) setting. This change only
respects the environment variable method, not the config file method.
The algorithm in fugitive#extract_git_dir() is to move upwards in the
file system hierarchy until a sub-directory called .git is found. When
accessing a file on a network share from a Cygwin Vim and the file is not
within a git repo, this eventually causes a check for the existence of
//serverName/.git and //.git. Such checks are extremely slow so let's
avoid them.
This reverts commit 31dead6d80.
Generating the tags file after already loading the buffer burns me over
and over and over again, and I'm not convinced there was a problem to
begin with.
When using a :Gedit command from the :Gstatus window the git_dir was
being based on the window that was switched into in order to edit the
file. So if Fugitive switched into a window with a file from a different
Git repo (or a file with no Git repo) the :Gedit command could fail or
edit the wrong file.
Instead base the git_dir on the window from which the :Gedit command
originated.
Vim does not guarantee persistent window numbers. Instead, windows are
numbered according to their position on the screen, with the topmost,
leftmost window always having number 1, and the bottommost, rightmost
window always having a number equal to the total number of windows
currently visible. Crucially, this means that, when a window is closed,
windows which come "after" it in the positional order will be
renumbered.
When fugitive's Gblame window is closed, e.g. by pressing `q`, it
attempts to return focus to the window of the blamed buffer. Previously,
the number of the window to return to was computed before closing the
Gblame window, then the Gblame window was closed, then the blamed
buffer's window was focused. However, since windows were often
renumbered as soon as the Gblame window was closed, this would
frequently cause focus to jump to the window *after* the blamed buffer's
window, rather than the intended behavior.
This corrects the issue by jumping to the proper return window prior to
deleting the Gblame buffer, ensuring that the computed window number is
in fact correct at the moment when the focus change occurs.
