{"thread":{"id":"7719","subject":"fetch: Auto-following tags should check connectivity, not existence","startedAt":"2007-04-17T16:10:43Z","lastAt":"2007-04-20T10:30:56Z","messageCount":3,"participants":["Johannes Sixt","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"39668","messageId":"4624F183.D4B6BBB1@eudaptics.com","threadId":"7719","inReplyTo":null,"subject":"fetch: Auto-following tags should check connectivity, not existence","fromName":"Johannes Sixt","fromEmail":"j.sixt@eudaptics.com","sentAt":"2007-04-17T16:10:43Z","receivedAt":"2007-04-17T16:10:43Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"git-fetch's auto-following of tags fetches all tags for which it finds\nobjects in the local repository. I feel it were better if not object\nexistence, but connectivity to the existing refs was checked, like this:\n\ndiff --git a/git-fetch.sh b/git-fetch.sh\nindex fd70696..1b3c459 100755\n--- a/git-fetch.sh\n+++ b/git-fetch.sh\n@@ -314,11 +314,12 @@ case \"$no_tags$tags\" in\n        taglist=$(IFS=' ' &&\n        echo \"$ls_remote_result\" |\n        git-show-ref --exclude-existing=refs/tags/ |\n        while read sha1 name\n        do\n-           git-cat-file -t \"$sha1\" >/dev/null 2>&1 || continue\n+           t=$(git-rev-list --max-count=1 \"$sha1\" --not --all 2>\n/dev/null) &&\n+           test -z \"$t\" || continue\n            echo >&2 \"Auto-following $name\"\n            echo \".${name}:${name}\"\n        done)\n    esac\n    case \"$taglist\" in\n\nIs this considered in the shell-to-C rewrite that's currently going on?\n\nThe background is that I sometimes fetch a branch with tags, but then\ndecide to remove it (and the tags as well). git-gc and git-prune do not\nguarantee that the objects go away because they could be reachable from\nreflogs. Now the next git-fetch will fetch the tags again even though I\ndo not have any refs from which they would be reachable.\n\n-- Hannes\n"},{"id":"39945","messageId":"7v4pnb4kil.fsf@assigned-by-dhcp.cox.net","threadId":"7719","inReplyTo":"4624F183.D4B6BBB1@eudaptics.com","subject":"Re: fetch: Auto-following tags should check connectivity, not existence","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-04-20T06:39:30Z","receivedAt":"2007-04-20T06:39:30Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Sixt <J.Sixt@eudaptics.com> writes:\n\n> git-fetch's auto-following of tags fetches all tags for which it finds\n> objects in the local repository. I feel it were better if not object\n> existence, but connectivity to the existing refs was checked, like this:\n>\n> diff --git a/git-fetch.sh b/git-fetch.sh\n> index fd70696..1b3c459 100755\n> --- a/git-fetch.sh\n> +++ b/git-fetch.sh\n> @@ -314,11 +314,12 @@ case \"$no_tags$tags\" in\n>         taglist=$(IFS=' ' &&\n>         echo \"$ls_remote_result\" |\n>         git-show-ref --exclude-existing=refs/tags/ |\n>         while read sha1 name\n>         do\n> -           git-cat-file -t \"$sha1\" >/dev/null 2>&1 || continue\n> +           t=$(git-rev-list --max-count=1 \"$sha1\" --not --all 2>\n> /dev/null) &&\n> +           test -z \"$t\" || continue\n>             echo >&2 \"Auto-following $name\"\n>             echo \".${name}:${name}\"\n>         done)\n>     esac\n>     case \"$taglist\" in\n\nI think \"something like this\" is a sensible thing to do, on top\nof the updates to \"rev-list --objects\" to verify the blob we\nlist actually exists.\n\nHowever, I think --max-count=1 defeats what you are trying to\ndo.  Revision limiting will only look at commits, and if you\nhave all commits that lead to the \"$sha1\" commit from some of\nthe existing refs, but lack some blobs or trees that belong to\nsome of the commits that are not the first commit that will be\nlisted, their absense will not be noticed.\n"},{"id":"39957","messageId":"7vvefr1gnz.fsf@assigned-by-dhcp.cox.net","threadId":"7719","inReplyTo":"7v4pnb4kil.fsf@assigned-by-dhcp.cox.net","subject":"Re: fetch: Auto-following tags should check connectivity, not existence","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-04-20T10:30:56Z","receivedAt":"2007-04-20T10:30:56Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <junkio@cox.net> writes:\n\n> Johannes Sixt <J.Sixt@eudaptics.com> writes:\n>\n>> git-fetch's auto-following of tags fetches all tags for which it finds\n>> objects in the local repository. I feel it were better if not object\n>> existence, but connectivity to the existing refs was checked, like this:\n> ...\n> However, I think --max-count=1 defeats what you are trying to\n> do.  Revision limiting will only look at commits, and if you\n> have all commits that lead to the \"$sha1\" commit from some of\n> the existing refs, but lack some blobs or trees that belong to\n> some of the commits that are not the first commit that will be\n> listed, their absense will not be noticed.\n\nSorry, but I have to take this back, after looking at your patch\nonce again.  In this case, all you are interested in is to see\nif the commit ancestry is connected, and you do not mind if the\nchain is somewhat incomplete in blobs and trees, as you will\nre-fetch the chain in a safe manner in the later round.  In\nother words, the code does not have to be as strict as my\nquickfetch series, which tries to *omit* re-fetching\naltogether.\n\nSo --max-count=1 is fine, although it may not be much of an\noptimization in practice, it does not harm correctness in any\nway, as my previous message suggested.\n"}]}