git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
From: Pratyush Yadav <me@yadavpratyush.com>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: Mark Levedahl <mlevedahl@gmail.com>,
	"brian m. carlson" <sandals@crustytoothpaste.net>,
	git <git@vger.kernel.org>,
	Christian Couder <christian.couder@gmail.com>,
	Junio C Hamano <gitster@pobox.com>
Subject: Re: [PATCH] git-gui: Perform rescan on window focus-in
Date: Sun, 4 Aug 2019 18:23:15 +0530	[thread overview]
Message-ID: <1489be05-ab18-a3e5-dd38-3d5729ebe67a@yadavpratyush.com> (raw)
In-Reply-To: <nycvar.QRO.7.76.6.1908032225510.46@tvgsbejvaqbjf.bet>

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:
>>> https://github.com/git-for-windows/git/blob/master/CONTRIBUTING.md#performance-tests
>>
>> 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/many-files.sh 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:
> https://devblogs.microsoft.com/bharry/the-largest-git-repo-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.

-- 
Regards,
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:
  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=1489be05-ab18-a3e5-dd38-3d5729ebe67a@yadavpratyush.com \
    --to=me@yadavpratyush.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=christian.couder@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=mlevedahl@gmail.com \
    --cc=sandals@crustytoothpaste.net \
    --subject='Re: [PATCH] git-gui: Perform rescan on window focus-in' \
    /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).