Johannes Sixt <J.Sixt@xxxxxxxxxxxxx> writes:
> git-fetch's auto-following of tags fetches all tags for which it finds
> objects in the local repository. I feel it were better if not object
> existence, but connectivity to the existing refs was checked, like this:
>
> diff --git a/git-fetch.sh b/git-fetch.sh
> index fd70696..1b3c459 100755
> --- a/git-fetch.sh
> +++ b/git-fetch.sh
> @@ -314,11 +314,12 @@ case "$no_tags$tags" in
> taglist=$(IFS=' ' &&
> echo "$ls_remote_result" |
> git-show-ref --exclude-existing=refs/tags/ |
> while read sha1 name
> do
> - git-cat-file -t "$sha1" >/dev/null 2>&1 || continue
> + t=$(git-rev-list --max-count=1 "$sha1" --not --all 2>
> /dev/null) &&
> + test -z "$t" || continue
> echo >&2 "Auto-following $name"
> echo ".${name}:${name}"
> done)
> esac
> case "$taglist" in
I think "something like this" is a sensible thing to do, on top
of the updates to "rev-list --objects" to verify the blob we
list actually exists.
However, I think --max-count=1 defeats what you are trying to
do. Revision limiting will only look at commits, and if you
have all commits that lead to the "$sha1" commit from some of
the existing refs, but lack some blobs or trees that belong to
some of the commits that are not the first commit that will be
listed, their absense will not be noticed.
-
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