From: Pratyush Yadav <firstname.lastname@example.org> To: Johannes Schindelin <Johannes.Schindelin@gmx.de> Cc: Mark Levedahl <email@example.com>, "brian m. carlson" <firstname.lastname@example.org>, git <email@example.com>, Christian Couder <firstname.lastname@example.org>, Junio C Hamano <email@example.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: <firstname.lastname@example.org> (raw) In-Reply-To: <nycvar.QRO.email@example.com> 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
next prev parent 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 \ --firstname.lastname@example.org \ --email@example.com \ --cc=Johannes.Schindelin@gmx.de \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --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).