list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
From: Pratyush Yadav <>
To: Johannes Schindelin <>
Cc: Mark Levedahl <>,
	"brian m. carlson" <>,
	git <>,
	Christian Couder <>,
	Junio C Hamano <>
Subject: Re: [PATCH] git-gui: Perform rescan on window focus-in
Date: Sun, 4 Aug 2019 18:23:15 +0530	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On 8/4/19 2:04 AM, Johannes Schindelin wrote:
> Hi,
> On Sat, 3 Aug 2019, Pratyush Yadav wrote:
>> On 8/2/19 6:09 PM, Johannes Schindelin wrote:
>>> On Fri, 2 Aug 2019, Pratyush Yadav wrote:
>>>> On 8/1/19 1:12 AM, Johannes Schindelin wrote:
>>>>> I would be _extremely_ cautious to base an argument on one
>>>>> particular setup, using on particular hardware with one
>>>>> particular OS and one particular repository.
>>>> Agreed. That's why I asked for benchmarks from other people.
>>>> Unfortunately, no one replied.
>>> What stops _you_ from performing more tests yourself? There are tons
>>> of real-world repositories out there, we even talk about options for
>>> large repositories to test with in Git for Windows' Contributing
>>> Guidelines:
>> I thought the point was to not base all data off a single setup?
> You misunderstood what I was saying: a single setup is bad, and you can
> make it moderately better by testing _at least_ with a moderately-sized
> repository [*1*] in addition to git.git.
> So yes, it would still not be enough to test with, say, the git.git
> _and_ the Chromium repository _only_ on your setup, but if not even you
> can be bothered to test with more than one small repository, how can you
> possibly expect anybody else to add more testing?

All right, I'll see what repos I can test.

But my internet is pretty slow and unstable, so my clone of the Chromium 
repo failed mid-way multiple times. I assume we need to test on a large 
index, so is it all right if I use t/perf/repos/ to 
artificially generate a large repo?

>> [...]
>>> I wonder, however, whether you can think of a better method to
>>> figure out when to auto-refresh. Focus seems to be a low-hanging
>>> fruit, but as you noticed it is not very accurate. Maybe if you
>>> combine it with a timeout? Or maybe you can detect idle time in
>>> Tcl/Tk?
>> Hm, I don't see a better alternative than file system watches.
>> Timeouts are a heuristic that can potentially be problematic.
> Let me stress the fact that I suggested a timeout _in addition_ to the
> focus event?

Oh, my bad. I thought you suggested using timeouts exclusively.

But I'm not sure I understand what you mean by "using timeouts in 
addition to the focus event". My guess is that you mean we should 
activate a refresh-on-focus-in only after git-gui has been out of focus 
for a certain amount of time. Is my guess correct?

> Yes, using a timeout on its own is stupidly problematic. That's why I
> did not suggest that.
>> If you do a refresh too frequently, you hog up the user's resources
>> for little benefit.
> Indeed. You want to find a heuristic that catches most of the cases
> where files were changed, while at the same time not even _trying_ to
> refresh automatically when probably nothing changed.

Like I said before, the best way of doing that that I can see is file 
system watches. But maybe we can get reasonable performance with a 
combination of timeouts and focus events.

>> You don't refresh frequently enough, then sometimes the user sees an
>> updated view, sometimes a not-updated view. This inconsistency, if not
>> fine tuned properly, can prove detrimental to UX.
> Right, exactly. And of course, since you are not changing your own Git
> fork only, but the Git that is the one that most users will use, you
> will have to consider carefully in which direction to strike the balance
> by default.

Yep, that's why I'm engaging you in this conversation :). I'm personally 
pretty happy with this change for my own use, but I'd like everyone 
enjoy it equally.

> I would contend that you should err on the side of _not_ refreshing, as
> that would probably affect more users negatively than the opposite.
> Ciao,
> Johannes
> Footnote *1*: I don't expect you to test with the largest repositories,
> as you are unlikely to have access to anything approaching the size of
> the largest Git repository on the planet:

Ah yes, I read about it a while back on Reddit. Having a huge monolithic 
repo sounds backwards to me. Using submodules sounds like a better idea, 
but who am I to judge. They probably have their reasons that I'm not 
aware of.

Pratyush Yadav

  reply	other threads:[~2019-08-04 12:53 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-28 15:17 Pratyush Yadav
2019-07-28 21:36 ` brian m. carlson
2019-07-28 22:10   ` Pratyush Yadav
2019-07-28 22:32     ` Pratyush Yadav
2019-07-28 22:49     ` brian m. carlson
2019-07-29  2:24       ` Mark Levedahl
2019-07-29  2:26       ` Mark Levedahl
2019-07-29  2:28       ` Mark Levedahl
2019-07-29  8:15         ` Pratyush Yadav
2019-07-31 19:42           ` Johannes Schindelin
2019-08-01 21:52             ` Pratyush Yadav
2019-08-02 12:39               ` Johannes Schindelin
2019-08-02 20:00                 ` Pratyush Yadav
2019-08-03 20:34                   ` Johannes Schindelin
2019-08-04 12:53                     ` Pratyush Yadav [this message]
2019-08-04 19:10                       ` Johannes Schindelin
2019-08-04 20:17                         ` Pratyush Yadav
2019-08-02 16:47               ` Junio C Hamano
2019-08-02 20:13                 ` Pratyush Yadav
2019-08-04 18:56                   ` Johannes Schindelin
2019-07-29  5:09       ` Junio C Hamano
2019-07-29  8:44         ` Pratyush Yadav
2019-07-28 21:44 ` Pratyush Yadav

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:

  List information:

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

  git send-email \ \ \ \ \ \ \ \ \
    --subject='Re: [PATCH] git-gui: Perform rescan on window focus-in' \

* 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:

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).