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: Fri, 2 Aug 2019 03:22:09 +0530	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>


On 8/1/19 1:12 AM, Johannes Schindelin wrote:
> Hi,
> On Mon, 29 Jul 2019, Pratyush Yadav wrote:
>> On 29/07/19 7:58 AM, Mark Levedahl wrote:
>>> On 7/28/19 6:49 PM, brian m. carlson wrote:> On 2019-07-28 at
>>> 22:10:29, Pratyush Yadav wrote:
>>>>> The function is not documented, and I only started spelunking
>>>>> the code a couple days back, so I'll try to answer with what I
>>>>> know. It might not be the full picture.
>>>>> Running git-gui --trace, these commands are executed during a rescan:
>>>>> /usr/lib/git-core/git-rev-parse --verify HEAD
>>>>> /usr/lib/git-core/git-update-index -q --unmerged --ignore-missing --refresh
>>>> Great. This sounds like a well-reasoned change. I'll let other folks who
>>>> use git-gui more chime in to see what they think as well.
>>> I'm assuming this does what is currently done by F5.
>>> A simple rescan from git-gui in the git repository takes about 8 seconds on
>>> my corporate laptop running Windows, making this happen on change of window
>>> focus is definitely not a friendly change from my view point.
>> This is a Windows problem maybe? On my Linux machine with an almost dead hard
>> drive, it takes under 10ms to do a refresh on the git repository (which has
>> about 56,000 commits).
> 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.

I am worried about exactly this problem that other users will have 
performance problems. I usually reserve judgment till I see some actual 
benchmarks, but since in this case we aren't getting any, it is probably 
better to err on the side of caution.

> When it comes to repositories that are worked on actively, git.git is
> not actually a representative example, it is way smaller than what users
> deal with.

Out of curiosity, what would you consider large enough? The Linux kernel 
(855,753 commits as of writing this)?

> You might be one of those developers privileged enough to have a fast
> computer. Trying to extrapolate from such a vantage point does the rest
> of us Git users a big disservice.

Yes I have a pretty powerful machine in the processor department, but I 
have a rather slow hard disk. I assumed most people would have faster 
hard disks than me, but in hindsight, that might not be a good 
assumption to make.

> At this point, I am gently inclined against the presented approach, in
> particular given that even context menus reportedly trigger the re-scan
> (which I suspect might actually be a Linux-only issue, as context menus
> are top-level windows on X11, at least if I remember correctly, and I
> also seem to remember that they are dependent windows on Aqua and Win32,
> just to add yet another argument against overfitting considerations onto
> a single, specific setup).

All right, the patch in its current state can't fly. So what is the 
correct way to do this? I see the following options:

1. Add this as an option that is disabled by default, but people who 
don't mind it can enable it. This is the easiest to implement. But I 
leave it to you and Junio (and anyone else who wants to pitch in :)) to 
decide if it is a good idea.

2. Watch all files for changes. Atom does this for their git gui [0]. We 
can probably use watchman [1] for this, but this adds another external 

3. Leave this feature out. I of course don't like this option very much, 
and will probably have to run a fork, but if it is better for the 
project, it is better for the project.

Which option do you want to go with?

Naturally, my favourite option is number 1 because it will be the 
easiest to implement ;)


Pratyush Yadav

  reply	other threads:[~2019-08-01 21:52 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 [this message]
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
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).