emmanueltouzery

A possible mechanism could also be a buffer-scoped variable, possibly guarded by a function so that the mechanism could be changed in the future.

hmm I'm not sure what the whole procedure would be then. 1. create a blank buffer 2. fill it in with the contents of the file on that branch 3....

Right so that doesn't work. It does update the marks on the left of the buffer: the changes from that commit are not anymore shown as "updated lines". However if...

Maybe I don't understand you correctly regarding the `show` action. But my main idea would be to have the normal gitsigns actions work without the user needing to call them...

my bad, I understood you now. It would be a one-time call by my library to tell you which file and revision :+1:

Right so I just tried the `show` feature and... it works exactly as the fugitive uri workaround that I have now! Meaning when I ask to view commit `X`, it...

interestingly, i was using a slightly older version of gitsigns, 27aeb2e715c32cbb99aa0b326b31739464b61644. With that version I get the X^ behavior. I now tried the latest and with that version I don't...

as a complete bystander, i'd appreciate the `inactive_window_shortline` boolean, to differentiate between inactive or short_line buffers. However in an ideal world, it would be nice to be able to differentiate...

otherwise I started using this patch for my setup and it seems to work as expected with inactive_window_shortline=false 👍

I also tried to force servlet 3.0 for the protocol but it didn't change anything. ``` org.jboss.arquillian.protocol arquillian-protocol-servlet test 1.1.2.Final ``` And the relevant XML in the arquillian.xml and I...