Johannes Schindelin <[email protected]> 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 <[email protected]>
> ---
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
