Re: Auto Rescan - as plain text

[David Aguilar <davvid@gmail.com>]

On Wed, Jun 10, 2020 at 02:29:02PM +0530, Pratyush Yadav wrote:
> Hi Junio,
> 
> On 09/06/20 05:16PM, Junio C Hamano wrote:
> > Luigi Cantoni <luigic@fgcint.com> writes:
> > 
> > > Hi All,
> > > I have been using git for several years now and using git-cola.
> > > I just started up git gui and that is quite self explanatory and all
> > > the functions I use with git-cola appear to be there.
> > 
> > We used to see the maintainer of that project around here quite
> > frequently but haven't seen him for a while [jch: David Cc'ed].
> > 
> > By reading https://git-cola.github.io/about.html it seems that they
> > prefer to see problem reports and feature requests at
> > https://github.com/git-cola/git-cola/issues and not on this list.
> 
> The feature request is for git-gui, asking for auto rescan in git-gui 
> like git-cola has. So I think this is the right place for it. Though I 
> think its easy to miss that on a quick read of the email. I had to do a 
> double take too :-)

Hi, I'm glad you like git-cola.

In the OP missed it, the git-gui maintainer's repo is here:

https://github.com/prati0100/git-gui


> > > One thing I liked in git-cola was that it very quickly reflected my
> > > changes in its display window.
> > > I have looked in the options and I cannot see either a flag to set it
> > > to auto rescan or set a time for the auto rescan.
> > >
> > > Have I missed it and there is a way turn this on or give it a shorter
> > > time (if in fact it is does do it).
> > > If it is not offered could it become an option.
> > > I can see that some people may not feel the overhead for distributed
> > > system is worth having this on so they would want if off.
> > > It is not critical (just nice) as I know I can
> > > 1) rescan
> > > or 2) go off the file and back on again.
> > > It then displays the correct diff/updated contents.
> > >
> > > Thanks for any advise or help.
> 
> -- 
> Regards,
> Pratyush Yadav


I'd be happy to explain how we implemented the "live refresh feature
in git-cola.

We have a few different approaches.  First, we integrate with inotify
on Linux.  When we notice that files have been written, we refresh our
state.  That's the happy path.

On Windows someone wrote an equivalent thing using some Windows file
monitoring APIs.

I don't think we currently have a macOS file monitoring part yet, but I
imagine there's probably a way to do it there too.

We're in Python, so we had the flexibility of what Python provides.
Git GUI will have access to anything tcl/tk / wish can do, but I'm
not familiar enough to know what's possible.

One thing we did do for users that don't have native file monitoring, is
that someone requested a preference, eg. "gui.refreshOnFocus", which
would make the GUI refresh whenever it gets focus from the window
manager.  This can be helpful, though it will make it take that extra
hit every time you switch between windows.  That might be something
that's possible to implement if something like inotify is not available,
though, and can be convenient for users that don't mind the hit.

Question for Luigui, how do you refresh the GUI?
Do you click on the "Rescan" button, or do you use the "Ctrl-R" hotkey?

One very nice but subtle detail that is not immediately obvious
from your description of how git-cola works is that if you have a file
selected, and something changes, we refresh the diff and keep the
viewport at the same location so that the changes appear right there,
immediately.  You mentioned:

> or 2) go off the file and back on again.

Which suggests that you have to deselect the file and reselect it to get
git-gui to redo the diff display.  You'll also lose the scrollbar
position if you do that, eg. if you are scrolled in the middle of a
large diff, you're going to lose your place.  That's why we
special-cased this behavior in cola and made it so that the rescan
behavior will redo the diff when a file is selected.

We go through great effort in cola to handle this in the nicest way
possible.  We  retaining the scrollbar/viewport position, redo the
diff, and ensure that if the user had something selected in the
text area, and the diff changes, that we attempt to re-select the text
that they may have selected, even if it changed lines.  The selection is
moreso content-centric than line-centric.

If they had something selected that went away, then their text selection
will be lost, but that's totally expected and natural.

I have a lot of opinions about how that tool should work, whch is really
why git-cola exists.  The diff/index editing part is really the killer
feature.

I ask how you refresh the GUI because cola is designed to be driven
entirely by keyboard shortcuts, and has vim-like hotkeys because I dig
building upon existing conventions and my vim muscle memory.

My main sug for git-gui would be to make it so that you don't have to
use a mouse.  Making it so that it can do the entire partial
staging/unstaging/revert workflow using line selection and keyboard
hotkeys would be my personal sug for feature requests.

If someone adds it, please use the "s" hotkey to stage/unstage selected
lines (or the hunk at the text cursor position, if nothing is selected),
"ctrl-u" to revert changes the same way, and "ctrl-s" to stage/unstage
the entire file, would be my personal sugs.

Parity with git-cola is always a nice goal within reason ;-) that way
folks won't have to re-learn these hotkeys across the tools.
-- 
David