Johannes Schindelin <johannes.schindelin@xxxxxx> writes: > It is quite possible for, say, a remote HEAD to become broken, e.g. > when the default branch was renamed. > > We should still be able to pack our objects when such a thing happens; > simply ignore broken symrefs (because they cannot matter for the packing > process anyway). > > This fixes https://github.com/git-for-windows/git/issues/423 > > Signed-off-by: Johannes Schindelin <johannes.schindelin@xxxxxx> > --- It seems that the result of applying these two patches and log messages of them are the same with what I queued on 'pu', except that the first of these two patches adds a test with a wrong name and then this one does "oops, that was misnamed". So I'll keep what is already queued. Thanks. > reachable.c | 8 +++++++- > t/t6500-gc.sh | 2 +- > 2 files changed, 8 insertions(+), 2 deletions(-) > > diff --git a/reachable.c b/reachable.c > index 9cff25b..43616d4 100644 > --- a/reachable.c > +++ b/reachable.c > @@ -25,9 +25,15 @@ static void update_progress(struct connectivity_progress *cp) > static int add_one_ref(const char *path, const struct object_id *oid, > int flag, void *cb_data) > { > - struct object *object = parse_object_or_die(oid->hash, path); > struct rev_info *revs = (struct rev_info *)cb_data; > + struct object *object; > > + if ((flag & REF_ISSYMREF) && (flag & REF_ISBROKEN)) { > + warning("symbolic ref is dangling: %s", path); > + return 0; > + } > + > + object = parse_object_or_die(oid->hash, path); > add_pending_object(revs, object, ""); > > return 0; > diff --git a/t/t6500-gc.sh b/t/t6500-gc.sh > index 9a3a285..5d7d414 100755 > --- a/t/t6500-gc.sh > +++ b/t/t6500-gc.sh > @@ -30,7 +30,7 @@ test_expect_success 'gc -h with invalid configuration' ' > test_i18ngrep "[Uu]sage" broken/usage > ' > > -test_expect_failure 'gc removes broken refs/remotes/<name>/HEAD' ' > +test_expect_success 'gc is not aborted due to a stale symref' ' > git init remote && > ( > cd remote && -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html