Re: RFC: How should we handle un-deleted remote branches?

From: Andreas Heiduk <asheiduk@gmail.com>
Date: Apr 22, 2018, 07:41 UTC
Message-ID: <3fcd1b50-2aeb-0ea4-fea7-b5705e76c027@gmail.com>
In-Reply-To: <87in8mdqhr.fsf@evledraar.gmail.com>

Am 20.04.2018 um 14:14 schrieb Ævar Arnfjörð Bjarmason:

Show 6 quoted lines

> But this is a possible work-around:
> 
>     git init /tmp/empty.git
>     git remote add avar file:///tmp/empty.git
>     git remote prune avar
>     git remote remove avar

This won't do it also?

	git remote prune origin

Show 25 quoted lines

> I started to patch this, but I'm not sure what to do here. we could do
> some combination of:
> 
>  0. Just document the current behavior and leave it.
> 
>  1. Dig further down to see what other remotes reference these refs, and
>     just ignore any refspecs that don't explicitly reference
>     refs/remotes/<our_deleted_remote>/*.
> 
>     I.e. isn't the intention here to preserve a case where you have two
>     URLs for the same effective remote, not whene you have something
>     like a --mirror refspec? Unfortunately I can't ask the original
>     author :(
> 
>  2. Warn about each ref we didn't delete, or at least warn saying
>     there's undeleted refs under refs/remotes/<name>/*.
> 
>  3. Make 'git remote remove --force-deletion <name>' (or whatever the
>     flag is called) be a thing. But unless we do the next item this
>     won't be useful.
> 
>  4. Make 'git remote prune <name>' work in cases where we don't have a
>     remote called <name> anymore, just falling back to deleting
>     refs/remotes/<name>. In this case 'git remote remove
>     --force-deletion <name>' would also do the same thing.

Possible 5):

	Don't fix "git remote remove" but "git remote add" to complain that its
ref-namespace is already occupied by some other remote. Add "--force"
for the experts.