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

From: Johannes Sixt <j6t@kdbg.org>
Date: Dec 18, 2020, 18:07 UTC
Message-ID: <dbe7278e-8a2c-e208-e482-435b9194c0d7@kdbg.org>
In-Reply-To: <1271e604-d016-1ddf-8370-49f5d3db44be@haller-berlin.de>

Am 18.12.20 um 11:36 schrieb Stefan Haller:

Show 9 quoted lines

> On 17.12.20 20:45, 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.
> 
> I tried to reproduce this, but couldn't. It would be helpful if you
> could post a more detailed reproduction recipe.

I cannot reproduce this on Linux. But I am on Windows most of the time, where it happens always. Note that you need two conflicted files. For example (in a temporary git.git worktree):

   git checkout b4100f366c1e~
   git -c rerere.enabled=0 merge b4100f366c1e^2

Select the second conflicted file, invoke the merge tool via the context menu, resolve the conflict, save and close the merge tool. Notice that the first conflicted file is now selected.

Note that a rescan happens automatically even without the patch under discussion when the merge tool (when invoked via the context menu) is closed. This patch starts a simultaneous rescan. Perhaps it is a timing problem of some sort.

Show 5 quoted lines

> Another related aspect: if you select an untracked file and then trigger
> a manual rescan, the file is no longer selected; it selects the first
> tracked, modified file instead. I don't know why it does this, I find
> this annoying. The auto-rescan doesn't have this behavior, it keeps the
> untracked file selected, which I like.

The idea behind the old behavior is that a change is more important than an untracked file. Also, a conflicted file is more important than a change; hence, if you have a normal unstaged change selected, and then rescan, a conflicted file is selected.

Show 9 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.
> 
> Like Pratyush, I can't see why this should happen, and I can't reproduce
> it on my machine (Mac). What system are you on?

I can reproduce this on my Linux box the same way as it happens on Windows. Just have two files with changes, then activate another window such that the unstaged file list remains visible, then click on the unselected file in Git GUI. Notice that it is not selected after Git GUI becomes active.

-- Hannes