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.
With 'shellslash' set, tempname() returns a filename with forward
slashes, which trips up the type command if we don't translate to
backslashes first.
Fixes half of #212.
In 1.7.10, the git-file switched from using an absolute to a relative
path. Treat any path starting with "." as relative. (A more robust
check for a relative path is more complicated than looking for a leading
slash because of Windows.)
Closes#201.
