Gblame P gets lost after following renames

[matthewd]

If I :Gblame a file which has recently been renamed, P will follow the relevant lines back through history... but when I then use gq to get back to reality, it tries to return me to a local file with whatever historical name I was just looking at, instead of taking me back to where I started.

[tpope]

Can you specify the exact buffer names in question?

[matthewd]

When I tried to reproduce this by finding renames on other repos, I instead hit #607.

It does still occur where I first saw it, though, so there must be something different about the renames in question(?)...

cd manageiq # https://github.com/ManageIQ/manageiq
vim Gemfile
:1
:Gblame
Pgq   # returns to current Gemfile
:Gblame
PPgq  # opens an empty vmdb/Gemfile buffer

As for why I sometimes see this and sometimes #607.. I'm really not sure. It's not specifically because the new name is a substring of the old one -- ManageIQ/manageiq's gems/pending/Gemfile, nee lib/Gemfile, shows the same behaviour.

And it's not related to the basename matching; rails/rails's railties/exe/rails nee railties/bin/rails manifested the #607 error instead.

[tpope]

Oh whoops I completely skimmed over the "rename" bit; this completely makes sense. Not sure what to do about it.

[matthewd]

Is it possible to carry along the original filename a la b:fugitive_blame_arguments? Or even as an argument? ¯_(ツ)_/¯

[tpope]

What happens if you start :Gblame when you are already editing a historical buffer?

[matthewd]

I guess I'd consider that an unavoidable edge case: if you start traversing from some mid-point (and the file stops existing at some point), then we truly can't get you to the current version of that file -- indeed it may simply not exist by any name.

So I guess I'd say if we don't already have a better idea of the original filename, we'd take the path from the current historical buffer, and keep that -- as we move further back in history, the name-fidelity can only get worse -- and then when the time comes, we just hope that your starting point had the right name.

At least in that case, we never had better knowledge to start with, so we have a good excuse... if you start on a real file, we're forgetting something we did once know.

[tpope]

I would be okay with passing along the original filename/buffer number, I guess. There are no more buffer variables but we store the arguments in s:temp_files, could put it there as well. This wouldn't work for <CR> though, because that visits more than just blame buffers. I consider <CR> to be vastly superior to P, so I will not be pursuing this. (But don't let that stop you!)

See also #988.