Re: [PATCH v3 1/2] merge: new autosetupmerge option 'simple' for matching branches

From: Tao Klerks <tao@klerks.biz>
Date: Mar 20, 2022, 17:00 UTC
Message-ID: <CAPMMpohKRq0N8MGcWmUfMxVLTXrMD-+ADBDp_W6xwOXjUxdkhA@mail.gmail.com>
In-Reply-To: <CAPMMpoi9gQscSQ5Xn1xTb6WaCXu+qR67DJh9nCbqN0jp7-b_5A@mail.gmail.com>

On Wed, Mar 2, 2022 at 10:35 AM Tao Klerks <tao@klerks.biz> wrote:

Show 27 quoted lines

>
> On Mon, Feb 28, 2022 at 11:56 AM Ævar Arnfjörð Bjarmason
> <avarab@gmail.com> 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.

Show 11 quoted lines

> > 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.