{"thread":{"id":"35223","subject":"fetch: tag following too ambitious?","startedAt":"2013-10-28T12:42:35Z","lastAt":"2013-10-28T16:34:19Z","messageCount":2,"participants":["Michael Haggerty","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"229638","messageId":"526E5BBB.6080306@alum.mit.edu","threadId":"35223","inReplyTo":null,"subject":"fetch: tag following too ambitious?","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2013-10-28T12:42:35Z","receivedAt":"2013-10-28T12:42:35Z","isPatch":false,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"When investigating the exact semantics of tag-following, I discovered\nthat the tag auto-following behavior of \"git fetch\" is more ambitious\nthan I would have expected: it fetches any tag that references an object\nthat is known to the local repository, *even if that object is not\ncurrently reachable* (i.e., neither reachable before the fetch or after\nthe fetch of non-auto-followed references).  This makes it hard to\nrenounce interest in a branch.\n\nSuppose there is a remote repo with\n\n    o---o---o        <- master\n     \\\n      o---A---B      <- pu\n\nWhen I clone this repo, of course I get all of the commits and both\nbranches.\n\nNow suppose I decide I'm not interested in \"branch\" anymore, so I delete\nits remote-tracking branch from my repository and change the config to\nonly fetch \"master\":\n\n    git config remote.origin.fetch \\\n            '+refs/heads/master:refs/remotes/origin/master'\n    git update-ref -d refs/remotes/origin/pu\n\nIt looks like I'm free of the \"pu\" branch, right?\n\nBut if a week later somebody pushes a tag \"t\" to origin that points at\ncommit A, and then I do\n\n    git fetch origin\n\nthen Git (un)helpfully fetches tag \"t\" into my repo, because even though\ncommit \"A\" isn't reachable in my repo, it hasn't been pruned yet from\nthe object database.\n\nI admit this is not likely to be a serious problem in practice, but I\nfound it surprising and strangely disturbing.  I would call it a bug.\n\nThoughts?\n\nMichael\n\n-- \nMichael Haggerty\nmhagger@alum.mit.edu\nhttp://softwareswirl.blogspot.com/\n"},{"id":"229647","messageId":"xmqq1u35gxro.fsf@gitster.dls.corp.google.com","threadId":"35223","inReplyTo":"526E5BBB.6080306@alum.mit.edu","subject":"Re: fetch: tag following too ambitious?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-10-28T16:34:19Z","receivedAt":"2013-10-28T16:34:19Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael Haggerty <mhagger@alum.mit.edu> writes:\n\n> When investigating the exact semantics of tag-following, I discovered\n> that the tag auto-following behavior of \"git fetch\" is more ambitious\n> than I would have expected: it fetches any tag that references an object\n> that is known to the local repository, *even if that object is not\n> currently reachable* (i.e., neither reachable before the fetch or after\n> the fetch of non-auto-followed references).  This makes it hard to\n> renounce interest in a branch.\n>\n> Suppose there is a remote repo with\n>\n>     o---o---o        <- master\n>      \\\n>       o---A---B      <- pu\n>\n> When I clone this repo, of course I get all of the commits and both\n> branches.\n>\n> Now suppose I decide I'm not interested in \"branch\" anymore, so I delete\n> its remote-tracking branch from my repository and change the config to\n> only fetch \"master\":\n>\n>     git config remote.origin.fetch \\\n>             '+refs/heads/master:refs/remotes/origin/master'\n>     git update-ref -d refs/remotes/origin/pu\n>\n> It looks like I'm free of the \"pu\" branch, right?\n>\n> But if a week later somebody pushes a tag \"t\" to origin that points at\n> commit A, and then I do\n>\n>     git fetch origin\n>\n> then Git (un)helpfully fetches tag \"t\" into my repo, because even though\n> commit \"A\" isn't reachable in my repo, it hasn't been pruned yet from\n> the object database.\n>\n> I admit this is not likely to be a serious problem in practice, but I\n> found it surprising and strangely disturbing.  I would call it a bug.\n\nSounds like a bug to me.  Does upload-pack to pack-object codepath\nactually pack the tag object and give it to you, or is it done all\nby reconnecting an existing and dangling tag back to your ref\nnamespace?\n"}]}