| Message ID | 20201101170505.71246-1-stefan@haller-berlin.de (mailing list archive) |
|---|---|
| Headers | show |
| Series | git-gui: Auto-rescan on activate | expand |
Hi Stefan, On 01/11/20 06:05PM, Stefan Haller wrote: > Do an automatic rescan whenever the git-gui window receives focus. Most other > GUI tools do this, and it's very convenient; no more pressing F5 manually. I submitted a patch for this a while back but there was a lengthy discussion. [0] would be a good read. IIRC the major blocker was that rescan is a very expensive operation on Windows. > People who don't like this behavior can turn it off using > "git config gui.autorescan false". To make sure the experience on Windows (and for anyone who faces long rescan times) does not degrade, I think we should keep this off by default. That said, I would love to be convinced to keep this on by default because IMO this is a really good feature to have. I tried coming up with ways to avoid slowdowns while keeping the auto rescan on but I didn't come up with anything convincing. > Stefan Haller (2): > git-gui: Delay rescan until idle time > git-gui: Auto-rescan on activate > > git-gui.sh | 26 ++++++++++++++++++++++---- > 1 file changed, 22 insertions(+), 4 deletions(-) > [0] https://lore.kernel.org/git/20190728151726.9188-1-me@yadavpratyush.com/
On 02.11.20 14:15, Pratyush Yadav wrote: > Hi Stefan, > > On 01/11/20 06:05PM, Stefan Haller wrote: >> Do an automatic rescan whenever the git-gui window receives focus. Most other >> GUI tools do this, and it's very convenient; no more pressing F5 manually. > > I submitted a patch for this a while back but there was a lengthy > discussion. [0] would be a good read. IIRC the major blocker was that > rescan is a very expensive operation on Windows. Ah, thanks for reminding me of that. I did actually read the discussion back then, but had completely forgotten about it. >> People who don't like this behavior can turn it off using >> "git config gui.autorescan false". > > To make sure the experience on Windows (and for anyone who faces long > rescan times) does not degrade, I think we should keep this off by > default. That said, I would love to be convinced to keep this on by > default because IMO this is a really good feature to have. I tried > coming up with ways to avoid slowdowns while keeping the auto rescan on > but I didn't come up with anything convincing. I still think the default should be on; I consider it more important that the information is accurate than that it is shown without delay. I do use Windows occasionally myself, in a slow VM no less, and it does annoy me that a rescan is so slow there; however, I still prefer that over looking at stale information without realizing it. Also, I had a look at how other git clients deal with this. I didn't do an exhaustive research, just quickly looked at a few: - Fork (https://git-fork.com) Rescans on activate. There's no setting to turn this off. (!) - SourceTree (https://www.sourcetreeapp.com) Rescans on activate. There's an option to turn this off, but it defaults to on. (It is confusingly called "Refresh automatically when files change", which doesn't seem to be accurate, as far as I can tell.) - Visual Studio Code Rescans on activate. There's an option to turn it off, but it defaults to on. - Sublime Merge (https://www.sublimemerge.com) Watches files and rescans in the background. So I would say there's plenty of precedence for having this behavior default to on. >> Stefan Haller (2): >> git-gui: Delay rescan until idle time >> git-gui: Auto-rescan on activate >> >> git-gui.sh | 26 ++++++++++++++++++++++---- >> 1 file changed, 22 insertions(+), 4 deletions(-) >> > > [0] https://lore.kernel.org/git/20190728151726.9188-1-me@yadavpratyush.com/ >
Am 01.11.20 um 18:05 schrieb Stefan Haller: > Do an automatic rescan whenever the git-gui window receives focus. Most other > GUI tools do this, and it's very convenient; no more pressing F5 manually. > > People who don't like this behavior can turn it off using > "git config gui.autorescan false". > > Stefan Haller (2): > git-gui: Delay rescan until idle time > git-gui: Auto-rescan on activate > > git-gui.sh | 26 ++++++++++++++++++++++---- > 1 file changed, 22 insertions(+), 4 deletions(-) > I've been using these patches in the past days. I am still a bit ambivalent on whether I like the behavior. I do switch among windows *a lot* and there is a short flicker on every rescan. And there is muscle memory... I observe a bug and a half: It is unclear which file is selected automatically when there are unstaged changes. But there is one misbehavior: after I have invoked the merge tool, resolved the conflict, and then switch back to Git GUI, the conflicted file is not selected anymore when it is not the first file in the list. That is *very* annoying. And then there is the following use-case. While Git GUI is not active (think Git GUI and Gitk side-by-side and Gitk active), I click on a particular file that is not at the top of the list; then Git GUI becomes active and rescans, but also forgets on which file I have clicked. But I expected the clicked-on file to become visible, which it doesn't, and I have to click again. This is mildly annoying. -- Hannes
Hi, On 17/12/20 08:45PM, Johannes Sixt wrote: > Am 01.11.20 um 18:05 schrieb Stefan Haller: > > Do an automatic rescan whenever the git-gui window receives focus. Most other > > GUI tools do this, and it's very convenient; no more pressing F5 manually. > > > > People who don't like this behavior can turn it off using > > "git config gui.autorescan false". > > > > Stefan Haller (2): > > git-gui: Delay rescan until idle time > > git-gui: Auto-rescan on activate > > > > git-gui.sh | 26 ++++++++++++++++++++++---- > > 1 file changed, 22 insertions(+), 4 deletions(-) > > > > I've been using these patches in the past days. > > I am still a bit ambivalent on whether I like the behavior. I do switch > among windows *a lot* and there is a short flicker on every rescan. And > there is muscle memory... This is part of the reason I am a little uneasy enabling it by default, and why I insist on having a loud and clear warning to the users about what is going on. > I observe a bug and a half: > > It is unclear which file is selected automatically when there are > unstaged changes. But there is one misbehavior: after I have invoked the > merge tool, resolved the conflict, and then switch back to Git GUI, the > conflicted file is not selected anymore when it is not the first file in > the list. That is *very* annoying. Haven't had a chance to try this out yet but AFAIK the last file should be correctly remembered. See below. > And then there is the following use-case. While Git GUI is not active > (think Git GUI and Gitk side-by-side and Gitk active), I click on a > particular file that is not at the top of the list; then Git GUI becomes > active and rescans, but also forgets on which file I have clicked. But I > expected the clicked-on file to become visible, which it doesn't, and I > have to click again. This is mildly annoying. Hmm, I don't see that on my system on Linux. The code to remember last open file is there in 'rescan_done'. So I don't understand why this becomes a problem on your system.
Am 17.12.20 um 21:10 schrieb Pratyush Yadav: > On 17/12/20 08:45PM, Johannes Sixt wrote: >> It is unclear which file is selected automatically when there are >> unstaged changes. But there is one misbehavior: after I have invoked the >> merge tool, resolved the conflict, and then switch back to Git GUI, the >> conflicted file is not selected anymore when it is not the first file in >> the list. That is *very* annoying. > > Haven't had a chance to try this out yet but AFAIK the last file should > be correctly remembered. See below. It doesn't here in the case where I invoke the merge tool via the context menu in the diff view. >> And then there is the following use-case. While Git GUI is not active >> (think Git GUI and Gitk side-by-side and Gitk active), I click on a >> particular file that is not at the top of the list; then Git GUI becomes >> active and rescans, but also forgets on which file I have clicked. But I >> expected the clicked-on file to become visible, which it doesn't, and I >> have to click again. This is mildly annoying. > > Hmm, I don't see that on my system on Linux. The code to remember last > open file is there in 'rescan_done'. So I don't understand why this > becomes a problem on your system. It's not "last open file"; that works ok. It is "file A is open, I click on file B, then rescan happens, now file A is still open"; at that point I want file B open---that's where I clicked. The important part is that the single click on file B must do two things: activate Git GUI, and switch to file B. It worked that way in the past. -- Hannes
Hi Johannes, thanks for testing! It's good to have people who care about details. On 17.12.20 20:45, Johannes Sixt wrote: > Am 01.11.20 um 18:05 schrieb Stefan Haller: >> Do an automatic rescan whenever the git-gui window receives focus. Most other >> GUI tools do this, and it's very convenient; no more pressing F5 manually. >> >> People who don't like this behavior can turn it off using >> "git config gui.autorescan false". >> >> Stefan Haller (2): >> git-gui: Delay rescan until idle time >> git-gui: Auto-rescan on activate >> >> git-gui.sh | 26 ++++++++++++++++++++++---- >> 1 file changed, 22 insertions(+), 4 deletions(-) >> > > I've been using these patches in the past days. > > I am still a bit ambivalent on whether I like the behavior. I do switch > among windows *a lot* and there is a short flicker on every rescan. And > there is muscle memory... Yes, the flicker is annoying. It also happens when you manually rescan (F5) though, so it's not a new problem. You just see it more often now. I didn't succeed to fix it yet, but I also didn't try very hard. Another problem that's related and can be annoying is that the text selection is lost on rescan; so if you select some lines because you want to stage them, and then before staging you briefly switch back to your editor to check something else, then you have to start over when you come back. I guess this could be fixed by remembering the selection on rescan, in a similar way how we remember the scroll position. As for muscle memory, in my experience this is something that you unlearn pretty quickly. On the contrary, I'm now having having trouble using git gui on machines that don't have the patch, because I got so used to relying on the window to always be up to date automatically. For me, I have to say that the auto-rescan is a total game-changer, even with all the problems that it still has. I don't want to do without it any more. > It is unclear which file is selected automatically when there are > unstaged changes. But there is one misbehavior: after I have invoked the > merge tool, resolved the conflict, and then switch back to Git GUI, the > conflicted file is not selected anymore when it is not the first file in > the list. That is *very* annoying. I tried to reproduce this, but couldn't. It would be helpful if you could post a more detailed reproduction recipe. Another related aspect: if you select an untracked file and then trigger a manual rescan, the file is no longer selected; it selects the first tracked, modified file instead. I don't know why it does this, I find this annoying. The auto-rescan doesn't have this behavior, it keeps the untracked file selected, which I like. > And then there is the following use-case. While Git GUI is not active > (think Git GUI and Gitk side-by-side and Gitk active), I click on a > particular file that is not at the top of the list; then Git GUI becomes > active and rescans, but also forgets on which file I have clicked. But I > expected the clicked-on file to become visible, which it doesn't, and I > have to click again. This is mildly annoying. Like Pratyush, I can't see why this should happen, and I can't reproduce it on my machine (Mac). What system are you on? -Stefan
Am 18.12.20 um 11:36 schrieb Stefan Haller: > On 17.12.20 20:45, Johannes Sixt wrote: >> It is unclear which file is selected automatically when there are >> unstaged changes. But there is one misbehavior: after I have invoked the >> merge tool, resolved the conflict, and then switch back to Git GUI, the >> conflicted file is not selected anymore when it is not the first file in >> the list. That is *very* annoying. > > I tried to reproduce this, but couldn't. It would be helpful if you > could post a more detailed reproduction recipe. I cannot reproduce this on Linux. But I am on Windows most of the time, where it happens always. Note that you need two conflicted files. For example (in a temporary git.git worktree): git checkout b4100f366c1e~ git -c rerere.enabled=0 merge b4100f366c1e^2 Select the second conflicted file, invoke the merge tool via the context menu, resolve the conflict, save and close the merge tool. Notice that the first conflicted file is now selected. Note that a rescan happens automatically even without the patch under discussion when the merge tool (when invoked via the context menu) is closed. This patch starts a simultaneous rescan. Perhaps it is a timing problem of some sort. > Another related aspect: if you select an untracked file and then trigger > a manual rescan, the file is no longer selected; it selects the first > tracked, modified file instead. I don't know why it does this, I find > this annoying. The auto-rescan doesn't have this behavior, it keeps the > untracked file selected, which I like. The idea behind the old behavior is that a change is more important than an untracked file. Also, a conflicted file is more important than a change; hence, if you have a normal unstaged change selected, and then rescan, a conflicted file is selected. >> And then there is the following use-case. While Git GUI is not active >> (think Git GUI and Gitk side-by-side and Gitk active), I click on a >> particular file that is not at the top of the list; then Git GUI becomes >> active and rescans, but also forgets on which file I have clicked. But I >> expected the clicked-on file to become visible, which it doesn't, and I >> have to click again. This is mildly annoying. > > Like Pratyush, I can't see why this should happen, and I can't reproduce > it on my machine (Mac). What system are you on? I can reproduce this on my Linux box the same way as it happens on Windows. Just have two files with changes, then activate another window such that the unstaged file list remains visible, then click on the unselected file in Git GUI. Notice that it is not selected after Git GUI becomes active. -- Hannes