git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
From: Stefan Haller <lists@haller-berlin.de>
To: Johannes Sixt <j6t@kdbg.org>, Stefan Haller <stefan@haller-berlin.de>
Cc: me@yadavpratyush.com, git@vger.kernel.org
Subject: Re: [PATCH 0/2] git-gui: Auto-rescan on activate
Date: Fri, 18 Dec 2020 11:36:00 +0100	[thread overview]
Message-ID: <1271e604-d016-1ddf-8370-49f5d3db44be@haller-berlin.de> (raw)
In-Reply-To: <e5f6753b-10b3-1291-1b39-34af63792037@kdbg.org>

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

  parent reply	other threads:[~2020-12-18 10:39 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-01 17:05 Stefan Haller
2020-11-01 17:05 ` [PATCH 1/2] git-gui: Delay rescan until idle time Stefan Haller
2020-11-02 15:45   ` Pratyush Yadav
2020-11-02 19:29     ` Stefan Haller
2020-11-01 17:05 ` [PATCH 2/2] git-gui: Auto-rescan on activate Stefan Haller
2020-11-02 15:48   ` Pratyush Yadav
2020-11-02 19:31     ` Stefan Haller
2020-11-02 13:15 ` [PATCH 0/2] " Pratyush Yadav
2020-11-02 19:24   ` Stefan Haller
2020-11-03 16:16     ` [PATCH v2 0/1] " Stefan Haller
2020-11-03 16:16       ` [PATCH v2 1/1] " Stefan Haller
2020-11-14 19:14         ` Stefan Haller
2020-11-17  7:36           ` Pratyush Yadav
2020-11-17 11:13             ` Stefan Haller
2020-11-17 12:05               ` Pratyush Yadav
2020-11-18  9:17                 ` Stefan Haller
2020-12-17 19:45 ` [PATCH 0/2] " Johannes Sixt
2020-12-17 20:10   ` Pratyush Yadav
2020-12-17 22:21     ` Johannes Sixt
2020-12-18 10:36   ` Stefan Haller [this message]
2020-12-18 18:07     ` Johannes Sixt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1271e604-d016-1ddf-8370-49f5d3db44be@haller-berlin.de \
    --to=lists@haller-berlin.de \
    --cc=git@vger.kernel.org \
    --cc=j6t@kdbg.org \
    --cc=me@yadavpratyush.com \
    --cc=stefan@haller-berlin.de \
    --subject='Re: [PATCH 0/2] git-gui: Auto-rescan on activate' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Code repositories for project(s) associated with this inbox:

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).