Re: [PATCH 0/2] git-gui: Auto-rescan on activate

From: Johannes Sixt <j6t@kdbg.org>
Date: Dec 17, 2020, 22:21 UTC
Message-ID: <f4e51020-e7e2-cfd6-7631-ca5f32850746@kdbg.org>
In-Reply-To: <20201217201051.am33p6h2xu6wq34s@yadavpratyush.com>

Am 17.12.20 um 21:10 schrieb Pratyush Yadav:

Show 9 quoted lines

> On 17/12/20 08:45PM, Johannes Sixt wrote:
>> It is unclear which file is selected automatically when there are
>> unstaged changes. But there is one misbehavior: after I have invoked the
>> merge tool, resolved the conflict, and then switch back to Git GUI, the
>> conflicted file is not selected anymore when it is not the first file in
>> the list. That is *very* annoying.
> 
> Haven't had a chance to try this out yet but AFAIK the last file should 
> be correctly remembered. See below.

It doesn't here in the case where I invoke the merge tool via the context menu in the diff view.

Show 10 quoted lines

>> And then there is the following use-case. While Git GUI is not active
>> (think Git GUI and Gitk side-by-side and Gitk active), I click on a
>> particular file that is not at the top of the list; then Git GUI becomes
>> active and rescans, but also forgets on which file I have clicked. But I
>> expected the clicked-on file to become visible, which it doesn't, and I
>> have to click again. This is mildly annoying.
> 
> Hmm, I don't see that on my system on Linux. The code to remember last 
> open file is there in 'rescan_done'. So I don't understand why this 
> becomes a problem on your system.

It's not "last open file"; that works ok. It is "file A is open, I click on file B, then rescan happens, now file A is still open"; at that point I want file B open---that's where I clicked. The important part is that the single click on file B must do two things: activate Git GUI, and switch to file B. It worked that way in the past.

-- Hannes