On Wed, Mar 2, 2022 at 10:35 AM Tao Klerks <tao@xxxxxxxxxx> wrote: > > On Mon, Feb 28, 2022 at 11:56 AM Ævar Arnfjörð Bjarmason > <avarab@xxxxxxxxx> wrote: > > > > > > This function is the only user of find_tracked_branch(). For e.g. "git > > checkout we emit"; > > > > fatal: builtin/checkout.c:1246: 'foo' matched multiple (4) remote tracking branches > > > > Perhaps we can do something similar here > > I'm not sure what you're pointing to specifically - the fact that the > checkout message provides a count? If so I guess I understand/agree, > find_tracked_branch() could be enhanced to keep counting rather than > exiting at the first sign of trouble, to support such a > slightly-more-explicit message here. > > I'm not convinced that this situation is common enough to warrant > change: mapping multiple remotes to the same remote-tracking path > seems like a strange setup - is this something we recommend or > document anywhere? maybe to have 2 "remotes" that correspond to the > same server over different protocols appear as one set of tracking > branches? > > On the other hand I am of course happy to make things better if we > think this will do that! Having finally understood the logic in play here, I now see that find_tracked_branch() does not "exit at the first sign of trouble" as I thought, so there isn't much change required to produce a marginally richer error message here, but I've decided to work on this proposed enhancement in a separate patch. The more I look at this, the less confident I am about exactly the right thing to do - and I'd rather not hold up the (in my opinion) net-good branch.autosetupmerge=simple work. The specific concern I have is about changing the "fatal: Not tracking: ambiguous information for ref refs/remotes/origin/master" message. Having understood when it can occur, I've realized it is probably quite common - I at least have certainly seen it a few times, as the situation it describes is what happens if you copy/paste a "remote" section in your git config file, to create a new remote with the same setup as an existing one, without remembering to adjust the refspec for the new remote name. > > even with some advise() > > emit information about what other branches conflicted. > > I believe the conflict is not about different "branches" exactly, but > about *refspecs* that map to the tracking branch. > > If I understand correctly this change would entail creating a new > advice type (and documenting it), and figuring out what the advice > should look like - something like "find and disambiguate your fetch > refspecs to enable auto tracking setup! If you want to keep your > ambiguous refspecs, set auto tracking setup to false!" - but nicer :) In addition to the mechanics of creating a new advice type, I eventually realized that the right message would list the *remotes* that have refspecs mapping to the same tracking ref - which would mean newly tracking those in the per-remote find_tracked_branch() looping. I initially thought this situation was too rare to warrant this kind of change, but now, understanding how I myself have reached this situation a few times *and it took me a while to understand what I did wrong* (at least the first time), I think it's worthwhile work in and of itself. Expect a new separate patchset sometime.
