From: Johannes Sixt <firstname.lastname@example.org> To: Stefan Haller <email@example.com>, Stefan Haller <firstname.lastname@example.org> Cc: email@example.com, firstname.lastname@example.org Subject: Re: [PATCH 0/2] git-gui: Auto-rescan on activate Date: Fri, 18 Dec 2020 19:07:58 +0100 [thread overview] Message-ID: <email@example.com> (raw) In-Reply-To: <firstname.lastname@example.org> Am 18.12.20 um 11:36 schrieb Stefan Haller: > 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. > 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. >> 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
prev parent reply other threads:[~2020-12-18 18:10 UTC|newest] Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-11-01 17:05 Stefan Haller 2020-11-01 17:05 ` [PATCH 1/2] git-gui: Delay rescan until idle time Stefan Haller 2020-11-02 15:45 ` Pratyush Yadav 2020-11-02 19:29 ` Stefan Haller 2020-11-01 17:05 ` [PATCH 2/2] git-gui: Auto-rescan on activate Stefan Haller 2020-11-02 15:48 ` Pratyush Yadav 2020-11-02 19:31 ` Stefan Haller 2020-11-02 13:15 ` [PATCH 0/2] " Pratyush Yadav 2020-11-02 19:24 ` Stefan Haller 2020-11-03 16:16 ` [PATCH v2 0/1] " Stefan Haller 2020-11-03 16:16 ` [PATCH v2 1/1] " Stefan Haller 2020-11-14 19:14 ` Stefan Haller 2020-11-17 7:36 ` Pratyush Yadav 2020-11-17 11:13 ` Stefan Haller 2020-11-17 12:05 ` Pratyush Yadav 2020-11-18 9:17 ` Stefan Haller 2020-12-17 19:45 ` [PATCH 0/2] " Johannes Sixt 2020-12-17 20:10 ` Pratyush Yadav 2020-12-17 22:21 ` Johannes Sixt 2020-12-18 10:36 ` Stefan Haller 2020-12-18 18:07 ` Johannes Sixt [this message]
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 \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [PATCH 0/2] git-gui: Auto-rescan on activate' \ /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).