{"thread":{"id":"11775","subject":"fetch : fetches tags?","startedAt":"2008-01-29T02:33:07Z","lastAt":"2008-01-29T17:08:49Z","messageCount":9,"participants":["Brandon Casey","Johannes Schindelin","Junio C Hamano","Shawn O. Pearce"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"66776","messageId":"479E9063.5000403@nrlssc.navy.mil","threadId":"11775","inReplyTo":null,"subject":"fetch : fetches tags?","fromName":"Brandon Casey","fromEmail":"casey@nrlssc.navy.mil","sentAt":"2008-01-29T02:33:07Z","receivedAt":"2008-01-29T02:33:07Z","isPatch":false,"sender":{"key":"drafnel@gmail.com","avatar":"https://avatars.githubusercontent.com/u/921167?v=4"},"body":"\nIs this the intended behavior?\n\nI'm pretty sure this was discussed recently on the list.\nMy understanding was that tags would only be fetched\nautomatically if a remote tracking branch was configured.\n\n$ cat .git/config\n[core]\n repositoryformatversion = 0\n filemode = true\n bare = false\n logallrefupdates = true\n\n\nI expect these to fetch tags automatically (and they do):\n\n git fetch\n git pull\n git fetch \n git pull \n\nI expect these to _not_ fetch tags (and they don't):\n\n git fetch \n git pull \n\nBut, I did not expect these to fetch tags:\n\n git fetch :\n git pull :\n\n\nThe association I am making here is between manually specifying\nthe repo and branch implying \"don't automatically fetch tags\",\nand fetch/pull automatically determining the branch (and repo)\nimplying \"automatically fetch tags\".\n\nThere is nothing automatic about that last form of fetch.\n\nI know there is --no-tags, and I know I can do\n\n git fetch \n git branch FETCH_HEAD\n\nBut neither are what I expected to have to do. So I guess the\ncolon notation implies remote tracking? I'm not sure I want\nthe tags by default when I call fetch this way. In this\ninstance I definitely did not want them.\n\n-brandon\n"},{"id":"66778","messageId":"alpine.LSU.1.00.0801290240240.23907@racer.site","threadId":"11775","inReplyTo":"479E9063.5000403@nrlssc.navy.mil","subject":"Re: fetch : fetches tags?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-01-29T02:41:28Z","receivedAt":"2008-01-29T02:41:28Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 28 Jan 2008, Brandon Casey wrote:\n\n> Is this the intended behavior?\n\nAFAICT yes. Whenever you say \"git fetch\" without \"--no-tags\", it should \nfetch those tags that reference objects that were fetched, and _only_ \nthose.\n\nHth,\nDscho\n\nP.S.: What does the Navy do with git?\n"},{"id":"66780","messageId":"7v3ashs5yg.fsf@gitster.siamese.dyndns.org","threadId":"11775","inReplyTo":"479E9063.5000403@nrlssc.navy.mil","subject":"Re: fetch : fetches tags?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-01-29T02:47:51Z","receivedAt":"2008-01-29T02:47:51Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Brandon Casey writes:\n\n> I expect these to fetch tags automatically (and they do):\n>\n> git fetch\n> git pull\n> git fetch \n> git pull \n>\n> I expect these to _not_ fetch tags (and they don't):\n>\n> git fetch \n> git pull \n>\n> But, I did not expect these to fetch tags:\n>\n> git fetch :\n> git pull :\n\nSigh... that matches my expectation.\n\nDid we break it when we overhauled \"git fetch\", or was this an\nindependent \"improvement\" that happened long before that?\n"},{"id":"66791","messageId":"479E9903.9000706@nrlssc.navy.mil","threadId":"11775","inReplyTo":"alpine.LSU.1.00.0801290240240.23907@racer.site","subject":"Re: fetch : fetches tags?","fromName":"Brandon Casey","fromEmail":"casey@nrlssc.navy.mil","sentAt":"2008-01-29T03:09:55Z","receivedAt":"2008-01-29T03:09:55Z","isPatch":false,"sender":{"key":"drafnel@gmail.com","avatar":"https://avatars.githubusercontent.com/u/921167?v=4"},"body":"Johannes Schindelin wrote:\n> Hi,\n> \n> On Mon, 28 Jan 2008, Brandon Casey wrote:\n> \n>> Is this the intended behavior?\n> \n> AFAICT yes. Whenever you say \"git fetch\" without \"--no-tags\", it should \n> fetch those tags that reference objects that were fetched, and _only_ \n> those.\n\nIt doesn't always fetch tags only when \"--no-tags\" is missing. Sometimes\nit refrains from fetching tags even when \"--no-tags\" is missing.\n\n$ mkdir test1 && cd test1 && git init && echo : > file1 && git add file1 &&\n git commit -m 'Commit1' file1 && git tag -m 'CommitTag1' tag1 && cd .. &&\n mkdir test2 && cd test2 && git init && git fetch ../test1 master &&\n git branch master FETCH_HEAD && cd ../test1 && echo -n 'Test1: ' &&\n git tag -n -l && cd ../test2 && echo -n 'Test2: ' && git tag -n -l | grep '' || echo 'NO TAGS'\n\nInitialized empty Git repository in .git/\nCreated initial commit 0f701fc: Commit1\n 1 files changed, 1 insertions(+), 0 deletions(-)\n create mode 100644 file1\nInitialized empty Git repository in .git/\nwarning: no common commits\nremote: Counting objects: 3, done.\nremote: Total 3 (delta 0), reused 0 (delta 0)\nUnpacking objects: 100% (3/3), done.\nTest1: tag1 CommitTag1\nTest2: NO TAGS\n\n\nNotice the last two lines.\n\n\nBut, change that fetch to master:master and...\n\n$ mkdir test1 && cd test1 && git init && echo : > file1 && git add file1 &&\n git commit -m 'Commit1' file1 && git tag -m 'CommitTag1' tag1 && cd .. &&\n mkdir test2 && cd test2 && git init && git fetch ../test1 master:master &&\n cd ../test1 && echo -n 'Test1: ' && git tag -n -l && cd ../test2 &&\n echo -n 'Test2: ' && git tag -n -l | grep '' || echo 'NO TAGS'\n\nInitialized empty Git repository in .git/\nCreated initial commit d67022e: Commit1\n 1 files changed, 1 insertions(+), 0 deletions(-)\n create mode 100644 file1\nInitialized empty Git repository in .git/\nwarning: no common commits\nremote: Counting objects: 3, done.\nremote: Total 3 (delta 0), reused 0 (delta 0)\nUnpacking objects: 100% (3/3), done.\nFrom ../test1\n * [new branch] master -> master\nremote: Counting objects: 1, done.\nremote: Total 1 (delta 0), reused 0 (delta 0)\nUnpacking objects: 100% (1/1), done.\nFrom ../test1\n * [new tag] tag1 -> tag1\nTest1: tag1 CommitTag1\nTest2: tag1 CommitTag1\n\n\nI only get the tags if I use the colon notation.\n\n-brandon\n\n\n> \n> Hth,\n> Dscho\n> \n> P.S.: What does the Navy do with git?\n\nManage software of course! What a silly question.\n\nKidding aside. I work with oceanographers.\n"},{"id":"66804","messageId":"20080129041928.GL24004@spearce.org","threadId":"11775","inReplyTo":"7v3ashs5yg.fsf@gitster.siamese.dyndns.org","subject":"Re: fetch : fetches tags?","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2008-01-29T04:19:29Z","receivedAt":"2008-01-29T04:19:29Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Junio C Hamano wrote:\n> Brandon Casey writes:\n> >\n> > But, I did not expect these to fetch tags:\n> >\n> > git fetch :\n> > git pull :\n> \n> Sigh... that matches my expectation.\n> \n> Did we break it when we overhauled \"git fetch\", or was this an\n> independent \"improvement\" that happened long before that?\n\nI think during the git-fetch builtin marathon this got implemented,\nbut probably as a feature masquerading as a bug fix and we didn't\nnotice the regression.\n\nThe theory behind the expectation here is if we are fetching the\nobject to a tracking ref then we probably want to watch it in\nthe future. If we want to watch it and tag following was allowed,\nand we are missing a tag, we should follow the tag if we have the\nobject graph under the tag complete.\n\nNow what should:\n\n\tgit pull : \n\ndo, especially if is referring to an object that you don't\nalready have, that object also isn't reachable through ,\nbut ^0 is the target of a tag that you don't have?\nShould we get the tag anyway?\n\nPersonally I'd expect us to skip the tag pointing at ^0,\nbased upon my description above, but I have a feeling we'd follow\nit anyway, as tag following was enabled and at least one item in\nthe fetchspec provided asked for storage to a tracking ref and we\nhave ^{} complete.\n\n\nOf course even if we didn't follow that tag right away a future:\n\n\tgit fetch :\n\nmight cause us to get the tag anyway, as ^0 is now reachable\nthrough HEAD, due to the implicit git-merge we ran above. ;-)\n\n-- \nShawn.\n"},{"id":"66805","messageId":"7vodb5qk2b.fsf@gitster.siamese.dyndns.org","threadId":"11775","inReplyTo":"7v3ashs5yg.fsf@gitster.siamese.dyndns.org","subject":"Re: fetch : fetches tags?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-01-29T05:26:04Z","receivedAt":"2008-01-29T05:26:04Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Brandon Casey writes:\n> ...\n>> I expect these to _not_ fetch tags (and they don't):\n>>\n>> git fetch \n>> git pull \n>>\n>> But, I did not expect these to fetch tags:\n>>\n>> git fetch :\n>> git pull :\n>\n> Sigh... that matches my expectation.\n>\n> Did we break it when we overhauled \"git fetch\", or was this an\n> independent \"improvement\" that happened long before that?\n\nHaving said that, I do not particularly think the new behaviour\nis bad per-se. If you are storing what you fetched locally in\ntracking branches, you are interested in their work enough to\nwant to auto-follow their tags.\n\nIt's just that the expectation you and I shared is the\ndocumented behaviour everywhere, and we would need to document\nthe new behaviour.\n"},{"id":"66825","messageId":"loom.20080129T055937-532@post.gmane.org","threadId":"11775","inReplyTo":"7vodb5qk2b.fsf@gitster.siamese.dyndns.org","subject":"Re: fetch : fetches tags?","fromName":"Brandon Casey","fromEmail":"drafnel@gmail.com","sentAt":"2008-01-29T08:46:19Z","receivedAt":"2008-01-29T08:46:19Z","isPatch":false,"sender":{"key":"drafnel@gmail.com","avatar":"https://avatars.githubusercontent.com/u/921167?v=4"},"body":"Junio C Hamano pobox.com> writes:\n\n> \n> Junio C Hamano pobox.com> writes:\n> \n> > Brandon Casey nrlssc.navy.mil> writes:\n> > ...\n> >> I expect these to _not_ fetch tags (and they don't):\n> >>\n> >> git fetch \n> >> git pull \n> >>\n> >> But, I did not expect these to fetch tags:\n> >>\n> >> git fetch :\n> >> git pull :\n> >\n> > Sigh... that matches my expectation.\n> >\n> > Did we break it when we overhauled \"git fetch\", or was this an\n> > independent \"improvement\" that happened long before that?\n> \n> Having said that, I do not particularly think the new behaviour\n> is bad per-se. If you are storing what you fetched locally in\n> tracking branches, you are interested in their work enough to\n> want to auto-follow their tags.\n\nHow is \"tracking\" defined? Is this a term that implies some configuration\nto link a local branch to a remote branch? Or is any local branch created\nfrom a remote branch considered \"tracking\"?\n\nI thought that a tracking branch needed some setup like what the --track\noption to git-branch or git-checkout would do. If setup is required, then\nit implies some permanence to the branch and for the link between the\nbranch and the remote. In this case I agree you would want to auto-follow\ntags.\n\n-brandon\n"},{"id":"66827","messageId":"7vabmpovu5.fsf@gitster.siamese.dyndns.org","threadId":"11775","inReplyTo":"loom.20080129T055937-532@post.gmane.org","subject":"Re: fetch : fetches tags?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-01-29T08:54:42Z","receivedAt":"2008-01-29T08:54:42Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Brandon Casey writes:\n\n>> Having said that, I do not particularly think the new behaviour\n>> is bad per-se. If you are storing what you fetched locally in\n>> tracking branches, you are interested in their work enough to\n>> want to auto-follow their tags.\n>\n> How is \"tracking\" defined? Is this a term that implies some configuration\n> to link a local branch to a remote branch? Or is any local branch created\n> from a remote branch considered \"tracking\"?\n\nI probably should have said \"Instead of just letting fetch\ntemporarily store the result in FETCH_HEAD and using it from\nthere, you saved it away; that's a good indication of you care\nabout it deeply enough\".\n\nIt's really about what's convenient. I was somewhat upset that\nthe behaviour change was not I was very aware of (perhaps I said\nit was a good idea and I then forgot), I didn't think the\nearlier behaviour was broken, but if I have to choose, I think\nthe new behaviour is probably slightly nicer than the old one.\n"},{"id":"66840","messageId":"479F5DA1.2030900@nrlssc.navy.mil","threadId":"11775","inReplyTo":"7vabmpovu5.fsf@gitster.siamese.dyndns.org","subject":"Re: fetch : fetches tags?","fromName":"Brandon Casey","fromEmail":"casey@nrlssc.navy.mil","sentAt":"2008-01-29T17:08:49Z","receivedAt":"2008-01-29T17:08:49Z","isPatch":false,"sender":{"key":"drafnel@gmail.com","avatar":"https://avatars.githubusercontent.com/u/921167?v=4"},"body":"Junio C Hamano wrote:\n> Brandon Casey writes:\n> \n>>> Having said that, I do not particularly think the new behaviour\n>>> is bad per-se. If you are storing what you fetched locally in\n>>> tracking branches, you are interested in their work enough to\n>>> want to auto-follow their tags.\n>> How is \"tracking\" defined? Is this a term that implies some configuration\n>> to link a local branch to a remote branch? Or is any local branch created\n>> from a remote branch considered \"tracking\"?\n> \n> I probably should have said \"Instead of just letting fetch\n> temporarily store the result in FETCH_HEAD and using it from\n> there, you saved it away; that's a good indication of you care\n> about it deeply enough\".\n> \n> It's really about what's convenient. I was somewhat upset that\n> the behaviour change was not I was very aware of (perhaps I said\n> it was a good idea and I then forgot), I didn't think the\n> earlier behaviour was broken, but if I have to choose, I think\n> the new behaviour is probably slightly nicer than the old one.\n\nIt feels a little inconsistent to me.\n\nWith this behavior adopted as standard, then all forms of fetch will\nfetch tags except for 'git-fetch '. I think this is\nprobably the least used form for porcelain.\n\nWhat I understand you to be saying is that creating a branch during\nfetch indicates \"I care deeply enough, so I want tags\". At the moment,\nI don't know why I would fetch if I didn't want to make a branch. Even\nif I just wanted to cherry-pick one patch, or one source file, or (some\nother contrived example), I think I would create a branch to give it\nsome anchor point, and why not create the branch during the fetch.\n\nAnd, if I fetch now with the colon notation implying I want tags, later,\nif I 'git pull ' from within that branch, why does that\nimply that I do not still want tags just because I'm not creating a 'new'\nbranch.\n\nI think the current metric for indicating \"caring deeply enough\" is the\nremote tracking configuration. Tracking implies \"I care deeply enough,\nI want tags\", lack of tracking does not imply this. But I said this already\nin another email. I am not sure if this feels right because it is documented\nor because it is right.\n\nAn alternative to this is to make fetch completely consistent so it either\n\"always\" gets tags, or \"never\" gets tags, and requires an option to reverse\nits behavior.\n\nIt seems to me that \"never\" gets tags is the safer choice. This is because\naccidentally fetching tags is a pain to clean up, but if I forget to ask\nfor tags, I just run the same command again and ask this time. If I fetch\nor pull and use the --tags (the current --tags should be changed to --all-tags)\nthen I know what I am doing.\n\nThe documented behavior for tracking branches and fetching tags could be\nretained by requiring a fetch option in the branch configuration and\nmodifying git-remote and commands that use --track, to add the option\nby default. The big downside is that this would require existing repositories\nto update their config file which would also cause confusion.\n\n-brandon\n"}]}