git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: Pratyush Yadav <me@yadavpratyush.com>
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: Sat, 3 Aug 2019 22:34:42 +0200 (CEST)	[thread overview]
Message-ID: <nycvar.QRO.7.76.6.1908032225510.46@tvgsbejvaqbjf.bet> (raw)
In-Reply-To: <a68f09be-949f-b16b-a585-9ca2a1991a4f@yadavpratyush.com>

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?

> [...]
> > 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?

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.

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

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/

  reply	other threads:[~2019-08-03 20:44 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 [this message]
2019-08-04 12:53                     ` Pratyush Yadav
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=nycvar.QRO.7.76.6.1908032225510.46@tvgsbejvaqbjf.bet \
    --to=johannes.schindelin@gmx.de \
    --cc=christian.couder@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=me@yadavpratyush.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).