From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: Git Mailing List <git@vger.kernel.org>
Subject: RFC: How should we handle un-deleted remote branches?
Date: Fri, 20 Apr 2018 14:14:24 +0200 [thread overview]
Message-ID: <87in8mdqhr.fsf@evledraar.gmail.com> (raw)
I removed a remote and its refs persisted. At first I thought this was a
bug but looking at add_branch_for_removal()'s "don't delete a branch if
another remote also uses it" logic it's intentional.
This goes very wrong if you do e.g.:
(
rm -rf /tmp/git &&
git clone --bare --mirror git@github.com:git/git.git /tmp/git &&
cd /tmp/git &&
git remote add avar git@github.com:avar/git.git &&
git fetch avar &&
git remote remove avar &&
git for-each-ref|grep -c refs/remotes/avar
)
At this point you can't prune it since no remote config is left:
$ git remote prune avar
fatal: 'avar' does not appear to be a git repository
fatal: Could not read from remote repository.
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
Or use update-ref -d to remove them:
for rr in $(git for-each-ref --format="%(refname)"|grep ^refs/remotes/avar/)
do
git update-ref -d $rr
done
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.
In any case, the current behavior where we just leave this crap behind
without any explanation or an obvious way to delete them (can't use
git-branch -d, need update-ref -d) isn't nice.
I encountered this in the wild because GitLab will add an "upstream" ref
if you clone a repo, but if you stop using the remote to update it in
combination with their "geo" remote (which has --mirror refspecs) it'll
leave behind all these dead refs.
next reply other threads:[~2018-04-20 12:14 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-20 12:14 Ævar Arnfjörð Bjarmason [this message]
2018-04-22 7:41 ` RFC: How should we handle un-deleted remote branches? Andreas Heiduk
2018-04-22 11:17 ` Ævar Arnfjörð Bjarmason
2018-04-22 14:30 ` Andreas Heiduk
2018-04-22 18:37 ` Ævar Arnfjörð Bjarmason
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 \
--in-reply-to=87in8mdqhr.fsf@evledraar.gmail.com \
--to=avarab@gmail.com \
--cc=git@vger.kernel.org \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public 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).