New fetcher configuration options aren't particularly welcome, as they
need documentation, tests, and create alternative code paths and
complexity.
 
That confirms my initial expectations, thanks for clarifying it.
 
Perhaps it would help if you show the sequence of steps that leads to
breakage, as it's hard to tell from just the description above what
the problem is exactly.
 
 
Sure. So first of all this is a git "problem" not a bitbake fetcher git.py lib "problem".
 
A developer created an upstream branch named "foo" with code changes
and changed a recipe SRC_URI to use the following:
 
SRC_URI = git://github.com/org/random-repo.git;protocol=https;branch=foo
 
do_fetch task was able to fetch everything properly during recipe build, storing it in DL_DIR as expected.
 
Second developer created the upstream branch "foo/bar" with code changes.
Meanwhile the first developer deleted the branch "foo" upstream.
 
The second developer updated the recipe to use the new branch:

SRC_URI = git://github.com/org/random-repo.git;protocol=https;branch=foo/bar
 
During do_fetch, git is not able to fetch the "foo/bar" branch as the parent reference "foo"
no longer exists in the upstream repo (only exists on local) triggering the error visible in the log.do_fetch
 
error: cannot lock ref 'refs/heads/foo/bar': 'refs/heads/foo' exists; cannot create 'refs/heads/foo/bar'
From https://github.com/org/random-repo
! [new branch]      foo/bar -> foo/bar  (unable to update local ref)

If I add back the --prune option that was removed here, "git fetch" will work with the following message
will appear in log.do_fetch
From https://github.com/org/random-repo
- [deleted]         (none)     -> foo
* [new branch]      foo/bar -> foo/bar