{"thread":{"id":"1929","subject":"Cogito: cg-clone doesn't like packed tag objects","startedAt":"2005-09-23T22:24:06Z","lastAt":"2005-11-10T01:01:46Z","messageCount":41,"participants":["H. Peter Anvin","Petr Baudis","Junio C Hamano","Daniel Barkalow","Brian Gerst","Tom Prince","Sven Verdoolaege","Ryan Anderson","Josef Weidendorfer","Linus Torvalds","Nick Hengeveld"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"9203","messageId":"43348086.2040006@zytor.com","threadId":"1929","inReplyTo":null,"subject":"Cogito: cg-clone doesn't like packed tag objects","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2005-09-23T22:24:06Z","receivedAt":"2005-09-23T22:24:06Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"Packed tag objects breaks Cogito when using git+ssh:// transport.\n\nExample:\n\ncg-clone -s git+ssh://master.kernel.org/pub/scm/libs/klibc/klibc.git\n\n\t-hpa\n"},{"id":"9213","messageId":"20050924011833.GJ10255@pasky.or.cz","threadId":"1929","inReplyTo":"43348086.2040006@zytor.com","subject":"Re: Cogito: cg-clone doesn't like packed tag objects","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-09-24T01:18:33Z","receivedAt":"2005-09-24T01:18:33Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Sat, Sep 24, 2005 at 12:24:06AM CEST, I got a letter\nwhere \"H. Peter Anvin\" <hpa@zytor.com> told me that...\n> Packed tag objects breaks Cogito when using git+ssh:// transport.\n> \n> Example:\n> \n> cg-clone -s git+ssh://master.kernel.org/pub/scm/libs/klibc/klibc.git\n\nI changed the code to use the git-*-fetch tools to fetch the objects\nreferenced by tags, so this works properly now. Thanks for the report.\n\nIt takes loooong time, unfortunately - scp -r takes its time itself on\nmany small files, and then we have to make a separate call to\ngit-ssh-fetch for each tag. Isn't that braindamaged... :/\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nVI has two modes: the one in which it beeps and the one in which\nit doesn't.\n"},{"id":"9215","messageId":"4334B178.4060408@zytor.com","threadId":"1929","inReplyTo":"20050924011833.GJ10255@pasky.or.cz","subject":"Re: Cogito: cg-clone doesn't like packed tag objects","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2005-09-24T01:52:56Z","receivedAt":"2005-09-24T01:52:56Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"Petr Baudis wrote:\n> \n> It takes loooong time, unfortunately - scp -r takes its time itself on\n> many small files, and then we have to make a separate call to\n> git-ssh-fetch for each tag. Isn't that braindamaged... :/\n> \n\nPerhaps git-ssh-fetch should be fixed?  :)\n\n\t-hpa\n"},{"id":"9216","messageId":"7vvf0r6x97.fsf@assigned-by-dhcp.cox.net","threadId":"1929","inReplyTo":"20050924011833.GJ10255@pasky.or.cz","subject":"Re: Cogito: cg-clone doesn't like packed tag objects","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-09-24T02:00:04Z","receivedAt":"2005-09-24T02:00:04Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Petr Baudis <pasky@suse.cz> writes:\n\n> It takes loooong time, unfortunately - scp -r takes its time itself on\n> many small files, and then we have to make a separate call to\n> git-ssh-fetch for each tag. Isn't that braindamaged... :/\n\nI think you could run git-peek-remote to find all the refs and\nthen run git-fetch-pack to slurp all the tags (and heads for\nthat matter) at once.  Is there a particular reason you would\nprefer the commit walker?\n"},{"id":"9223","messageId":"20050924125001.GB25069@pasky.or.cz","threadId":"1929","inReplyTo":"7vvf0r6x97.fsf@assigned-by-dhcp.cox.net","subject":"Re: Cogito: cg-clone doesn't like packed tag objects","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-09-24T12:50:01Z","receivedAt":"2005-09-24T12:50:01Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Sat, Sep 24, 2005 at 04:00:04AM CEST, I got a letter\nwhere Junio C Hamano <junkio@cox.net> told me that...\n> Petr Baudis <pasky@suse.cz> writes:\n> \n> > It takes loooong time, unfortunately - scp -r takes its time itself on\n> > many small files, and then we have to make a separate call to\n> > git-ssh-fetch for each tag. Isn't that braindamaged... :/\n> \n> I think you could run git-peek-remote to find all the refs and\n> then run git-fetch-pack to slurp all the tags (and heads for\n> that matter) at once.  Is there a particular reason you would\n> prefer the commit walker?\n\nActually, probably not, except consistency with rsync and http handling\n- but that's obviously not too good reason. I did it this way since I'm\ngoing to be a bit busy again from now on.\n\nI will probably rewrite the tags fetching to use git-peek-remote\n(info/refs for http) the next weekend. One problem with this is that in\nmany repositories, git-update-server-info does not get ever run and\nthings would break \"mysteriously\". I don't want the policy that the user\nhas to take care of this on his own for Cogito, so I will probably add\nsomething that will automagically append git-update-server-info at least\nto the post-update hook (like\n\n\tuphook=\"$_git/hooks/update-post\"\n\tif ! [ -x \"$uphook\" ]; then\n\t\tif ! [ -e \"$uphook\" ]; then\n\t\t\techo '#!/bin/sh' >>\"$uphook\"\n\t\t\techo 'exec git-update-server-info' >>\"$uphook\"\n\t\tfi\n\t\t# If the user added something custom and left the hook\n\t\t# disabled, he knew what he was doing. Also don't\n\t\t# reenable the hook if we already did that once.\n\t\tif [[ \"$(grep -v '^#\\($\\|[^#]\\)\\|^$' \"$uphook\")\" == \"*exec git-update-server-info*\" ]]; then\n\t\t\tchmod a+x \"$uphook\"\n\t\t\techo \"## Enabled by Cogito. It won't try to enable it again as long as this comment is here.\" >>\"$uphook\"\n\t\tfi\n\tfi\n\nor something).\n\nActually, I might also add something like\n\n\t[ -e \"$_git/git-dummy-support\" ] && git-update-server-info\n\nat all the places in Cogito where I update the refs. Then the\ndefault post-update hook could change to\n\n\t[ -e \"$_git/git-dummy-support\" ] && exec git-update-server-info\n\nand be enabled by default?\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nVI has two modes: the one in which it beeps and the one in which\nit doesn't.\n"},{"id":"9231","messageId":"Pine.LNX.4.63.0509241302450.23242@iabervon.org","threadId":"1929","inReplyTo":"20050924125001.GB25069@pasky.or.cz","subject":"Re: Cogito: cg-clone doesn't like packed tag objects","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2005-09-24T17:13:29Z","receivedAt":"2005-09-24T17:13:29Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Sat, 24 Sep 2005, Petr Baudis wrote:\n\n> Dear diary, on Sat, Sep 24, 2005 at 04:00:04AM CEST, I got a letter\n> where Junio C Hamano <junkio@cox.net> told me that...\n> > Petr Baudis <pasky@suse.cz> writes:\n> > \n> > > It takes loooong time, unfortunately - scp -r takes its time itself on\n> > > many small files, and then we have to make a separate call to\n> > > git-ssh-fetch for each tag. Isn't that braindamaged... :/\n> > \n> > I think you could run git-peek-remote to find all the refs and\n> > then run git-fetch-pack to slurp all the tags (and heads for\n> > that matter) at once.  Is there a particular reason you would\n> > prefer the commit walker?\n> \n> Actually, probably not, except consistency with rsync and http handling\n> - but that's obviously not too good reason. I did it this way since I'm\n> going to be a bit busy again from now on.\n\nIt wouldn't actually be very hard to rewrite git-*-fetch programs to fetch \nwith a bunch of starting points. The main reason I haven't is actually \nthat I don't have any ideas for a way to extend the command line argument \nformat to include it.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"9234","messageId":"7virwqwd3z.fsf@assigned-by-dhcp.cox.net","threadId":"1929","inReplyTo":"20050924125001.GB25069@pasky.or.cz","subject":"Re: Cogito: cg-clone doesn't like packed tag objects","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-09-24T18:10:40Z","receivedAt":"2005-09-24T18:10:40Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Petr Baudis <pasky@suse.cz> writes:\n\n>> I think you could run git-peek-remote to find all the refs and\n>> then run git-fetch-pack to slurp all the tags (and heads for\n>> that matter) at once.  Is there a particular reason you would\n>> prefer the commit walker?\n>\n> Actually, probably not, except consistency with rsync and http handling\n> - but that's obviously not too good reason.\n\nWe would end up doing things internally differently between\ngit-native (fetch/clone-pack) and other protocols (commit walker\nwhich is git-aware, and rsync which is not) anyway.\n\nI misspoke for 'git-fetch-pack' in the above -- git-fetch-pack\nwithout any refspec fetches all the refs, so you do not need a\nseparate peek-remote.  Right now 'git fetch' wrapper does not\nlet you take advantage of this, but if we wanted to add '--all'\nflag to 'git fetch' wrapper, it can be implemented very easily\nand efficiently for the git-native protocol.  An implementation\nof such a flag for other protocols would use git-ls-remote to\nfind out the refs upfront.\n\n> I will probably rewrite the tags fetching to use git-peek-remote\n> (info/refs for http) the next weekend.\n\nIf you are targetting multiple protocols, git-ls-remote is the\none to use, not peek-remote.  It internally uses peek-remote for\ngit-native protocol, and emulates it using info/refs for http\nand recursive get for rsync, so no new coding on Cogito part\nshould be necessary.\n\n> default post-update hook could change to\n>\n> \t[ -e \"$_git/git-dummy-support\" ] && exec git-update-server-info\n>\n> and be enabled by default?\n\nThat is a thought.  While I think doing update-server-info\neverywhere whenever you update ref is going a bit overboard, I\nagree there should be an easy way for the end user to keep\nrepositories that are public accessible all times.  But running\nserver-info upon every commit does not make much sense to me --\nsomething is seriously broken if we need to do that.\n\nCases when you would want to make your repository accessible\nfrom outside itself varies and preferred transport obviously\ndepends on it.\n\n - Your private working area.  Typically does not allow\n   anonymous downloads.  You are the only one to use git tools\n   and compilation there (that's what 'private' means).\n\n - A CVS style shared repository.  May allow anonymous\n   downloads, and allow uploads to people with 'commit\n   privilege' in CVS lingo.\n\n - A public distribution point, like kernel.org repository.\n   This is just a special case of the 'shared repository' above,\n   with yourself as the only uploader.\n\nI thought there would be more classes, but it really boils down\nto whether you would allow anonymous downloads or not -- so\nlet's call them private and public.\n\nFetching over non git-native protocol is the only case where\nserver-info matters; so obviously it is nicer if public\nrepository is arranged so that update-server-info is run\neverytime refs and set of packs change.\n\nI do not think of a good reason not to use git-aware protocol\nwhen one is fetching from a private repo -- so if we just say\npeople should not use non git-aware protocol when doing so, we\ndo not have to do server-info in the private repositories at\nall.\n\nSo the question is, how often do we need to run update to keep\nthe refs and set of packs in public repository in sync with the\nserver-info.  What do people do in public repository to affect\nset of packs and the refs?\n\n - Initiate a push into it from somewhere else; this case is\n   covered by enabling post-update hook.\n\n - You log on to the machine of public repository and run 'git\n   repack'; this runs update-server-info, so it is OK.\n\n - You log on to the machine of public repository and run fetch\n   of another repository -- you may even end up hand merging and\n   creating new commits.\n\n - You log on to the machine of public repository and do your\n   development, making your own commits.\n\nIt is the latter two cases where your 'update-server-info\neverywhere in Cogito' would be needed -- but is it realistic?\n"},{"id":"9330","messageId":"20050926212536.GF26340@pasky.or.cz","threadId":"1929","inReplyTo":"20050924011833.GJ10255@pasky.or.cz","subject":"Re: Cogito: cg-clone doesn't like packed tag objects","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-09-26T21:25:36Z","receivedAt":"2005-09-26T21:25:36Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Sat, Sep 24, 2005 at 03:18:33AM CEST, I got a letter\nwhere Petr Baudis <pasky@suse.cz> told me that...\n> Dear diary, on Sat, Sep 24, 2005 at 12:24:06AM CEST, I got a letter\n> where \"H. Peter Anvin\" <hpa@zytor.com> told me that...\n> > Packed tag objects breaks Cogito when using git+ssh:// transport.\n> > \n> > Example:\n> > \n> > cg-clone -s git+ssh://master.kernel.org/pub/scm/libs/klibc/klibc.git\n> \n> I changed the code to use the git-*-fetch tools to fetch the objects\n> referenced by tags, so this works properly now. Thanks for the report.\n\nAnd now thanks to \"walt\" I realized that this is a completely wrong way\nto go. The problem is that the tags don't have to tag anything on your\nbranch, and if you are fetching a given branch, you want only commits\nfrom that branch. But fetching the tags will cause all the commits\nconnected to the tags getting slurped too, and we didn't want that.\n\nSo the strategy I'm thinking of now is to manually (I think no GIT tool\ncan do that for me) dereference the possible tag chain until I end up at\nsome non-tag object. Now, if it is a commit and I don't have it yet, it\nmeans that it is not interesting to me because it does not belong to a\nbranch I'm following, so I will just ignore the tag (won't download\nanything else and won't record it in the refs/tags directory).\n\nIf it's NOT a commit, well, that's a question.  On the assumption that\nit won't be a great deal of data and it's likely to be assumed that we\nhave it, I would be inclined to fetching it, but I don't feel strongly\nabout it.\n\nThe ideal and the least expensive solution for this, obviously, would be\nhaving this logic in git-fetch-pack. :-)\n\nOpinions?\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nVI has two modes: the one in which it beeps and the one in which\nit doesn't.\n"},{"id":"9331","messageId":"43386E56.8000208@didntduck.org","threadId":"1929","inReplyTo":"20050926212536.GF26340@pasky.or.cz","subject":"Re: Cogito: cg-clone doesn't like packed tag objects","fromName":"Brian Gerst","fromEmail":"bgerst@didntduck.org","sentAt":"2005-09-26T21:55:34Z","receivedAt":"2005-09-26T21:55:34Z","isPatch":false,"sender":{"key":"bgerst@didntduck.org","avatar":null},"body":"Petr Baudis wrote:\n> Dear diary, on Sat, Sep 24, 2005 at 03:18:33AM CEST, I got a letter\n> where Petr Baudis <pasky@suse.cz> told me that...\n> \n>>Dear diary, on Sat, Sep 24, 2005 at 12:24:06AM CEST, I got a letter\n>>where \"H. Peter Anvin\" <hpa@zytor.com> told me that...\n>>\n>>>Packed tag objects breaks Cogito when using git+ssh:// transport.\n>>>\n>>>Example:\n>>>\n>>>cg-clone -s git+ssh://master.kernel.org/pub/scm/libs/klibc/klibc.git\n>>\n>>I changed the code to use the git-*-fetch tools to fetch the objects\n>>referenced by tags, so this works properly now. Thanks for the report.\n> \n> \n> And now thanks to \"walt\" I realized that this is a completely wrong way\n> to go. The problem is that the tags don't have to tag anything on your\n> branch, and if you are fetching a given branch, you want only commits\n> from that branch. But fetching the tags will cause all the commits\n> connected to the tags getting slurped too, and we didn't want that.\n> \n> So the strategy I'm thinking of now is to manually (I think no GIT tool\n> can do that for me) dereference the possible tag chain until I end up at\n> some non-tag object. Now, if it is a commit and I don't have it yet, it\n> means that it is not interesting to me because it does not belong to a\n> branch I'm following, so I will just ignore the tag (won't download\n> anything else and won't record it in the refs/tags directory).\n\nI think this is the right idea.\n\n> If it's NOT a commit, well, that's a question.  On the assumption that\n> it won't be a great deal of data and it's likely to be assumed that we\n> have it, I would be inclined to fetching it, but I don't feel strongly\n> about it.\n\nIt could point to a tree (ie. the kernel's v2.6.11 tag), which may end \nup being a large pull.  I think it's best to not care what type of \nobject the tag references.\n\n--\n\t\t\t\tBrian Gerst\n"},{"id":"9333","messageId":"20050926215647.GD26338@pasky.or.cz","threadId":"1929","inReplyTo":"43386E56.8000208@didntduck.org","subject":"Re: Cogito: cg-clone doesn't like packed tag objects","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-09-26T21:56:47Z","receivedAt":"2005-09-26T21:56:47Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Mon, Sep 26, 2005 at 11:55:34PM CEST, I got a letter\nwhere Brian Gerst <bgerst@didntduck.org> told me that...\n> Petr Baudis wrote:\n> >If it's NOT a commit, well, that's a question.  On the assumption that\n> >it won't be a great deal of data and it's likely to be assumed that we\n> >have it, I would be inclined to fetching it, but I don't feel strongly\n> >about it.\n> \n> It could point to a tree (ie. the kernel's v2.6.11 tag), which may end \n> up being a large pull.  I think it's best to not care what type of \n> object the tag references.\n\nYes, but the object may not be reachable in any other way.\n\nSimple question - if you have a tagged blob containing a GPG public key\n(let's call it.. hmm.. e.g. junio-gpg-pub ;), would you expect Cogito to\nignore it or pick it up?\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nVI has two modes: the one in which it beeps and the one in which\nit doesn't.\n"},{"id":"9340","messageId":"7virwna2oi.fsf@assigned-by-dhcp.cox.net","threadId":"1929","inReplyTo":"20050926212536.GF26340@pasky.or.cz","subject":"Re: Cogito: cg-clone doesn't like packed tag objects","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-09-26T22:23:41Z","receivedAt":"2005-09-26T22:23:41Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Petr Baudis <pasky@suse.cz> writes:\n\n> Opinions?\n\nI do not understand this part of your logic:\n\n> .... But fetching the tags will cause all the commits\n> connected to the tags getting slurped too, and we didn't want that.\n\nWhat is the objective here?  If you fetch a tag without the\nobject being tagged (or commit without its tree), you will end\nup with smaller object database but you would get yelled at by\ngit-fsck-objects.\n"},{"id":"9342","messageId":"20050926222944.GG26340@pasky.or.cz","threadId":"1929","inReplyTo":"7virwna2oi.fsf@assigned-by-dhcp.cox.net","subject":"Re: Cogito: cg-clone doesn't like packed tag objects","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-09-26T22:29:45Z","receivedAt":"2005-09-26T22:29:45Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Tue, Sep 27, 2005 at 12:23:41AM CEST, I got a letter\nwhere Junio C Hamano <junkio@cox.net> told me that...\n> Petr Baudis <pasky@suse.cz> writes:\n> > .... But fetching the tags will cause all the commits\n> > connected to the tags getting slurped too, and we didn't want that.\n> \n> What is the objective here?  If you fetch a tag without the\n> object being tagged (or commit without its tree), you will end\n> up with smaller object database but you would get yelled at by\n> git-fsck-objects.\n\nYes - so you can't save the tag objects either, but then you'll re-slurp\nthem again and again, which is kind of silly. Alternatively, you could\nactually make git-fsck-object silent about the case when an unreachable\n(not referenced in refs/) tag object references a non-existing object -\nperhaps unless --strict is passed to it. If you think the rest of my\nlogic is ok, I think this change to facilitate this \"tags caching\" is\nnot unreasonable.\n\nThe alternative solution would be to have the tags cache with the tag\nobjects separate of the main object database, but that'd be very dirty.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nVI has two modes: the one in which it beeps and the one in which\nit doesn't.\n"},{"id":"9344","messageId":"7v3bnra20z.fsf@assigned-by-dhcp.cox.net","threadId":"1929","inReplyTo":"7virwna2oi.fsf@assigned-by-dhcp.cox.net","subject":"Re: Cogito: cg-clone doesn't like packed tag objects","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-09-26T22:37:48Z","receivedAt":"2005-09-26T22:37:48Z","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> Petr Baudis <pasky@suse.cz> writes:\n>\n>> Opinions?\n>\n> I do not understand this part of your logic:\n>\n>> .... But fetching the tags will cause all the commits\n>> connected to the tags getting slurped too, and we didn't want that.\n>\n> What is the objective here?  If you fetch a tag without the\n> object being tagged (or commit without its tree), you will end\n> up with smaller object database but you would get yelled at by\n> git-fsck-objects.\n\nHaving said that, I am sympathetic to what you are trying to do\nhere; if what I understand what you are trying to do matches\nwhat you are actually trying to do, that is.\n\nI think there should be a way to say \"I do not care if this\nrepository does not have all the history back to root -- as long\nas I can operate on reasonably recent commits, do not complain\nabout missing objects\" to fsck-objects and various fetch\nengines.  We can cauterize commit history chain using the grafts\nfile so that 'git log', 'git whatchanged', and 'gitk' would stop\nsomewhere.  Commit walkers can help you, albeit somewhat\ndifferently, if you do not give -a flag to them.\n"},{"id":"9360","messageId":"7vr7bb5d8w.fsf@assigned-by-dhcp.cox.net","threadId":"1929","inReplyTo":"20050926222944.GG26340@pasky.or.cz","subject":"Re: Cogito: cg-clone doesn't like packed tag objects","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-09-27T04:46:39Z","receivedAt":"2005-09-27T04:46:39Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Petr Baudis <pasky@suse.cz> writes:\n\n> Yes - so you can't save the tag objects either, but then\n> you'll re-slurp them again and again, which is kind of\n> silly. Alternatively, you could actually make git-fsck-object\n> silent about the case when an unreachable (not referenced in\n> refs/) tag object references a non-existing object - perhaps\n> unless --strict is passed to it. If you think the rest of my\n> logic is ok, I think this change to facilitate this \"tags\n> caching\" is not unreasonable.\n\nNow you completely lost me.  I really do not understand what you\nmean by tags caching and re-slurping.\n\nIf your user _is_ interested in the tag, say v0.99.7d, wouldn't\nit make sense to make sure that, after the user fetches the tag,\nthe user can build v0.99.7d point release as well?  What do you\nthink the reason is when your user says he is interested in\nanother tag, junio-gpg-pub?  Wouldn't it be the most natural\ninterpretation that he wants to get the blob the tag refers to,\nso that he can use it with git-verify-tag?  What good does it do\nfor the user if you get only the tag object and do not get the\nblob the tag refers to?  Yes, he can say \"git cat-file tag\njunio-gpg-pub\", but that by itself is not that interesting if it\ncannot be used to validate the other tags (or itself).\n\nIf the users ask for a tag, I think it is easier for them to\nunderstand if you made sure you give them the complete set of\nobjects that need to support that tag, at least by default.\nGiving the user an option to override it to make a sparse,\nincomplete, fsck-unclean repository is fine as a spacesaver\noption, but I think that should be left for \"more advanced\nusers\" who understand the ramification of using the option.\n\nI happen to publish maint branch, but I could have done without.\nI can make a temporary branch out of v0.99.7c tag, add fixes to\nextend that branch, tag the branch head as v0.99.7d, and delete\nthe temporary branch without publishing it at all.\n\nThe tree needed to build v0.99.7d point release would be only\nreachable by fetching that tag (and here, \"fetching the tag\"\nreally means \"making sure the receiving repository has the tag\nobject, and all the objects that are reachable from that tag\nobject\"), so \"fetching only the tag object and not the object it\nrefers to\" in that case does not make much sense for the end\nuser.  Yes, he can say \"git cat-file tag v0.99.7d\", but that by\nitself is not that interesting if he cannot use it to build that\nrelease.\n"},{"id":"9361","messageId":"8764snyufn.fsf@ualberta.net","threadId":"1929","inReplyTo":"7vr7bb5d8w.fsf@assigned-by-dhcp.cox.net","subject":"Re: Cogito: cg-clone doesn't like packed tag objects","fromName":"Tom Prince","fromEmail":"tom.prince@ualberta.net","sentAt":"2005-09-27T05:02:36Z","receivedAt":"2005-09-27T05:02:36Z","isPatch":false,"sender":{"key":"tom.prince@ualberta.net","avatar":"https://gravatar.com/avatar/a0ad19caee7618876339485106ec994f5202505eecd210ba5c0bd869feaa555a?d=mp&s=160"},"body":"Junio C Hamano <junkio@cox.net> writes:\n\n> Petr Baudis <pasky@suse.cz> writes:\n>\n>> Yes - so you can't save the tag objects either, but then\n>> you'll re-slurp them again and again, which is kind of\n>> silly. Alternatively, you could actually make git-fsck-object\n>> silent about the case when an unreachable (not referenced in\n>> refs/) tag object references a non-existing object - perhaps\n>> unless --strict is passed to it. If you think the rest of my\n>> logic is ok, I think this change to facilitate this \"tags\n>> caching\" is not unreasonable.\n>\n> Now you completely lost me.  I really do not understand what you\n> mean by tags caching and re-slurping.\n>\n\nI think Petr is interested in the case where the user hasn't asked for a\nparticular tag. He wants to automatically grab all the tags in a repository,\nor at least those that refer to a branch being downloaded.\n\nOf course, if somebody asks for a specific tag, then everything necessary\nshould be downloaded. Somebody is fetching your maint branch, Petr want to\nautomatically download all the tags v0.99.7[a-d], without the user specifying\nthem explicitly. Or more complex, somebody is tracking your master but NOT\nmaint. Then Petr wants to download tags v0.99.[0-9] but not v0.99.7[a-d]. \n\n  Tom\n"},{"id":"9362","messageId":"7v4q875bbj.fsf@assigned-by-dhcp.cox.net","threadId":"1929","inReplyTo":"8764snyufn.fsf@ualberta.net","subject":"Re: Cogito: cg-clone doesn't like packed tag objects","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-09-27T05:28:16Z","receivedAt":"2005-09-27T05:28:16Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Tom Prince <tom.prince@ualberta.net> writes:\n\n> Junio C Hamano <junkio@cox.net> writes:\n>\n>> Now you completely lost me.  I really do not understand what you\n>> mean by tags caching and re-slurping.\n>\n> I think Petr is interested in the case where the user hasn't asked for a\n> particular tag. He wants to automatically grab all the tags in a repository,\n> or at least those that refer to a branch being downloaded.\n\nAh, _automatically_ was the key.\n\nIf all you had were tags and there were no branches (the \"I\ncould have done without maint branch\"), that kind of automatic\ngrabbing would not work well anyway.  I personally feel that is\na lost cause.  The user can run 'git ls-remote' himself to find\nout if there are new tags on the remote side and ask for them if\nneeded.\n\nAlso, I feel names under refs/ is local to the repository, but\nif the tags are automatically grabbed, I presume they are stored\ndirectly under the same name in refs/tags as the remote side has\nthem?\n"},{"id":"9368","messageId":"20050927065436.GL15165MdfPADPa@greensroom.kotnet.org","threadId":"1929","inReplyTo":"20050926212536.GF26340@pasky.or.cz","subject":"Re: Cogito: cg-clone doesn't like packed tag objects","fromName":"Sven Verdoolaege","fromEmail":"skimo@kotnet.org","sentAt":"2005-09-27T06:54:37Z","receivedAt":"2005-09-27T06:54:37Z","isPatch":false,"sender":{"key":"skimo@kotnet.org","avatar":null},"body":"On Mon, Sep 26, 2005 at 11:25:36PM +0200, Petr Baudis wrote:\n> So the strategy I'm thinking of now is to manually (I think no GIT tool\n> can do that for me) dereference the possible tag chain until I end up at\n> some non-tag object. \n\nIf it _is_ a commit, you could use \ngit-rev-list --max-count=1 $tag\n\nIt won't help you though if it isn't.\n\nskimo\n"},{"id":"9370","messageId":"4338F3F6.8040401@michonline.com","threadId":"1929","inReplyTo":"20050926212536.GF26340@pasky.or.cz","subject":"Re: Cogito: cg-clone doesn't like packed tag objects","fromName":"Ryan Anderson","fromEmail":"ryan@michonline.com","sentAt":"2005-09-27T07:25:42Z","receivedAt":"2005-09-27T07:25:42Z","isPatch":false,"sender":{"key":"ryan@michonline.com","avatar":null},"body":"Petr Baudis wrote:\n> So the strategy I'm thinking of now is to manually (I think no GIT tool\n> can do that for me) dereference the possible tag chain until I end up at\n> some non-tag object. Now, if it is a commit and I don't have it yet, it\n> means that it is not interesting to me because it does not belong to a\n> branch I'm following, so I will just ignore the tag (won't download\n> anything else and won't record it in the refs/tags directory).\n\ngit-rev-parse $tagname^0\n\n"},{"id":"9372","messageId":"7vll1j2bs3.fsf@assigned-by-dhcp.cox.net","threadId":"1929","inReplyTo":"20050926212536.GF26340@pasky.or.cz","subject":"Re: Cogito: cg-clone doesn't like packed tag objects","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-09-27T07:46:36Z","receivedAt":"2005-09-27T07:46:36Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Petr Baudis <pasky@suse.cz> writes:\n\n> If it's NOT a commit, well, that's a question.  On the assumption that\n> it won't be a great deal of data and it's likely to be assumed that we\n> have it, I would be inclined to fetching it, but I don't feel strongly\n> about it.\n\nv2.6.11 tag is not a commit but presumably it would slurp in a\nlot of data.\n"},{"id":"9376","messageId":"20050927094029.GA30889@pasky.or.cz","threadId":"1929","inReplyTo":"7v3bnra20z.fsf@assigned-by-dhcp.cox.net","subject":"Re: Cogito: cg-clone doesn't like packed tag objects","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-09-27T09:40:29Z","receivedAt":"2005-09-27T09:40:29Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Tue, Sep 27, 2005 at 07:28:16AM CEST, I got a letter\nwhere Junio C Hamano <junkio@cox.net> told me that...\n> Tom Prince <tom.prince@ualberta.net> writes:\n> \n> > Junio C Hamano <junkio@cox.net> writes:\n> >\n> >> Now you completely lost me.  I really do not understand what you\n> >> mean by tags caching and re-slurping.\n> >\n> > I think Petr is interested in the case where the user hasn't asked for a\n> > particular tag. He wants to automatically grab all the tags in a repository,\n> > or at least those that refer to a branch being downloaded.\n> \n> Ah, _automatically_ was the key.\n> \n> If all you had were tags and there were no branches (the \"I\n> could have done without maint branch\"), that kind of automatic\n> grabbing would not work well anyway.\n\nI don't think that's a realistic situation. IMHO it is a reasonable\nrequirement for Cogito fetch that you are primarily fetching a _head_.\nThen, you also grab tags which are meaningful for that head - that's\nwhat I want to do. If you want to also specifically grab some extra\ntags, you should be able to tell cg-fetch about that too (cg-fetch -t\ntagname) or something. Being able to do this, I'm inclined to agree that\nwe shouldn't grab even trees and blobs.\n\n> I personally feel that is a lost cause.  The user can run 'git\n> ls-remote' himself to find out if there are new tags on the remote\n> side and ask for them if needed.\n\nYes, that's perhaps a fine solution for the core GIT plumbing, but in\nCogito, I _really_ want to have this working automagically.\n\n> Also, I feel names under refs/ is local to the repository, but\n> if the tags are automatically grabbed, I presume they are stored\n> directly under the same name in refs/tags as the remote side has\n> them?\n\nYes. And I certainly don't say that what Cogito does now is perfect, not\neven that it's very good. But we (well, rather the users) certainly _do_\nneed some kind of automatic tags fetching - that's something that has to\nJust Work (tm).\n\nAs I already said in the past (without much feedback, unfortunately), we\ncertainly need to distinguish between private tags (specific for given\nrepository) and public tags (should be propagated by fetching).\n\nAnother thing I proposed back then (I think it was in June) was having\nthe refs/tags directory further divised based on heads, so all tags for\nhead A would be in refs/tags/A/, etc. I didn't pursue this idea now\nbecause it seemed that there would be way too many duplicate stuff in\nrefs/tags/ since most tags are likely to be shared across heads, but\nperhaps it is the beast and cleanest solution after all.\n\nDear diary, on Tue, Sep 27, 2005 at 12:37:48AM CEST, I got a letter\nwhere Junio C Hamano <junkio@cox.net> told me that...\n> I think there should be a way to say \"I do not care if this\n> repository does not have all the history back to root -- as long\n> as I can operate on reasonably recent commits, do not complain\n> about missing objects\" to fsck-objects and various fetch\n> engines.  We can cauterize commit history chain using the grafts\n> file so that 'git log', 'git whatchanged', and 'gitk' would stop\n> somewhere.  Commit walkers can help you, albeit somewhat\n> differently, if you do not give -a flag to them.\n\nWell, this wasn't something I had on my mind in this thread, but it is\nactually what I want to do too (I have such a loooong TODO list). Sure,\nyou can workaround the problem with grafts, but I think that this hack\nshould be really used only in specific cases (like grafting big history\npack after importing the project to GIT, making it kind of optional\n\"addon\", which is actually very nice). In the general case, I would much\nmore like if you could say \"I want only commits to the depth of 5\" or\neven CVS-like \"I want only the HEAD commit\" (actually, I received some\npatches to make Cogito support this, but I didn't yet get to have a look\nat them). This shifts the policy decision from the repository owner to\nthe user, and makes it contignuous instead of fragmented to the points\nwhen you have grafts.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nVI has two modes: the one in which it beeps and the one in which\nit doesn't.\n"},{"id":"9381","messageId":"200509271214.31933.Josef.Weidendorfer@gmx.de","threadId":"1929","inReplyTo":"20050927094029.GA30889@pasky.or.cz","subject":"Re: Cogito: cg-clone doesn't like packed tag objects","fromName":"Josef Weidendorfer","fromEmail":"josef.weidendorfer@gmx.de","sentAt":"2005-09-27T10:14:31Z","receivedAt":"2005-09-27T10:14:31Z","isPatch":false,"sender":{"key":"josef.weidendorfer@gmx.de","avatar":null},"body":"On Tuesday 27 September 2005 11:40, Petr Baudis wrote:\n> Another thing I proposed back then (I think it was in June) was having\n> the refs/tags directory further divised based on heads, so all tags for\n> head A would be in refs/tags/A/, etc. I didn't pursue this idea now\n> because it seemed that there would be way too many duplicate stuff in\n> refs/tags/ since most tags are likely to be shared across heads, but\n> perhaps it is the beast and cleanest solution after all.\n\nThe problem here is that currently there are no global, public branches.\nAnd you should not mix private heads in refs/heads with global tags.\nPerhaps interpret tag objects as global branch names, similar to\nthe \"mixture\" in .git/refs ?\n\nJosef\n"},{"id":"9385","messageId":"20050927123455.GE30889@pasky.or.cz","threadId":"1929","inReplyTo":"200509271214.31933.Josef.Weidendorfer@gmx.de","subject":"Re: Cogito: cg-clone doesn't like packed tag objects","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-09-27T12:34:55Z","receivedAt":"2005-09-27T12:34:55Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Tue, Sep 27, 2005 at 12:14:31PM CEST, I got a letter\nwhere Josef Weidendorfer <Josef.Weidendorfer@gmx.de> told me that...\n> On Tuesday 27 September 2005 11:40, Petr Baudis wrote:\n> > Another thing I proposed back then (I think it was in June) was having\n> > the refs/tags directory further divised based on heads, so all tags for\n> > head A would be in refs/tags/A/, etc. I didn't pursue this idea now\n> > because it seemed that there would be way too many duplicate stuff in\n> > refs/tags/ since most tags are likely to be shared across heads, but\n> > perhaps it is the beast and cleanest solution after all.\n> \n> The problem here is that currently there are no global, public branches.\n> And you should not mix private heads in refs/heads with global tags.\n\nBut we don't need any global tags or heads. You just have some heads in\nyour refs/heads (it doesn't matter if they are public or remote, that's\na \"social\" issue what you tell people to fetch). And based on your heads\nyou have in your refs/heads, there would be directories in your\nrefs/tags/ corresponding to those.\n\nIf you fetch remote head, its local subdirectory in refs/tags/ is\npopulated with the new tags, and if you merge two heads, the public tags\nare copied around. Then if you are resolving a tag, we should first look\nat refs/tags/$(readlink HEAD)/tagname, and if it doesn't exist, we would\nlook at refs/tags/tagname (so if you wanted to reference a tag not in\nyour head, you'd have to use a \"head/tag\" form). Optionally, you could\nalso look for refs/tags/*/tagname and if it gives you a unique match,\nuse that - but I'm not sure how good idea this is since it already makes\nthe lookup way too heuristical.\n\n> Perhaps interpret tag objects as global branch names, similar to\n> the \"mixture\" in .git/refs ?\n\nI don't understand.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nVI has two modes: the one in which it beeps and the one in which\nit doesn't.\n"},{"id":"9388","messageId":"200509271527.26050.Josef.Weidendorfer@gmx.de","threadId":"1929","inReplyTo":"20050927123455.GE30889@pasky.or.cz","subject":"Re: Cogito: cg-clone doesn't like packed tag objects","fromName":"Josef Weidendorfer","fromEmail":"josef.weidendorfer@gmx.de","sentAt":"2005-09-27T13:27:25Z","receivedAt":"2005-09-27T13:27:25Z","isPatch":false,"sender":{"key":"josef.weidendorfer@gmx.de","avatar":null},"body":"On Tuesday 27 September 2005 14:34, Petr Baudis wrote:\n> But we don't need any global tags or heads. You just have some heads in\n> your refs/heads (it doesn't matter if they are public or remote, that's\n> a \"social\" issue what you tell people to fetch). And based on your heads\n> you have in your refs/heads, there would be directories in your\n> refs/tags/ corresponding to those.\n\nAh, ok.\n\nLet me see if I understand:\n1) These tags are bound to a head, and they have the invariant that they \nappear in the commit history of the head.\n2) They are updated automatically.\n3) When someone rebases a head, the bound tags should be synced to the\nrebased head's history.\n4) Tags can appear multiple times, if they happen to be in the commit\nhistory of multiple heads?\n\nHow to make sure that the invariant mentioned in (1) always holds?\n\n> If you fetch remote head, its local subdirectory in refs/tags/ is\n> populated with the new tags, and if you merge two heads, the public tags\n> are copied around.\n\nOk, this is the \"automatically updated\" feature I talked about above.\nSo missing here is:\n- If you want to get rid of a head, the tags should be removed\n- If a head is rebased, this has to be detected and the tags recreated,\npossibly removing some\n\nProbably there should be a \"cg-tag --recover\" to resync these volatile\ntags with tag objects appearing in the histories of heads?\n\nAs for lightweight tags of remote repositories, you probably need some\nspace to recover them e.g. on a rebase or creation of a new head without\nrunning git-ls-remote all the time.\n\n> Then if you are resolving a tag, we should first look \n> at refs/tags/$(readlink HEAD)/tagname, and if it doesn't exist, we would\n> look at refs/tags/tagname (so if you wanted to reference a tag not in\n> your head, you'd have to use a \"head/tag\" form).\n\nSounds nice.\n\n> > Perhaps interpret tag objects as global branch names, similar to\n> > the \"mixture\" in .git/refs ?\n>\n> I don't understand.\n\nTag objects in a repository could be interpreted as branch names\nfor commits based on it. When creating a new branch point, I first\nwould put a tag object on this branch, thus renaming it.\nI think this would be quite handy for navigation in histories.\n\nJosef\n"},{"id":"9392","messageId":"Pine.LNX.4.58.0509270821590.3308@g5.osdl.org","threadId":"1929","inReplyTo":"4338F3F6.8040401@michonline.com","subject":"Re: Cogito: cg-clone doesn't like packed tag objects","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-09-27T15:34:22Z","receivedAt":"2005-09-27T15:34:22Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 27 Sep 2005, Ryan Anderson wrote:\n> \n> git-rev-parse $tagname^0\n\nYou need \"--verify\". Otherwise git-rev-parse will think that you just have \na strange filename or other random thing:\n\n\tprompt$ git-rev-parse 000^0\n\t000^0\n\n\tprompt$ git-rev-parse --verify 000^0\n\tfatal: Needed a single revision\n\nNow, if the tag doesn't point to a commit, then the \"^0\" thing will fail. \nWhat you could use instead is\n\n\tgit-rev-list --max-count=1 \"$tag\"\n\nsince git-rev-list will actually follow the tag. Of course, whether it \ndoes so correctly or not if the tagged object doesn't exist, I dunno. \nTesting needed.\n\nFinally, you might just do it by hand\n\n\ttype=$(git-cat-file -t \"$obj\") || exit\n\tif [ \"$type\" == \"$tag\" ]; then\n\t\ttagged=$(git-cat-file tag \"$obj\" |\n\t\t\tsed 's/object // ; q')\n\t\tgit-rev-parse --verify \"$tagged\"\n\tfi\n\nuntested, of course.\n\n\t\tLinus\n"},{"id":"9399","messageId":"7v64sm30dh.fsf@assigned-by-dhcp.cox.net","threadId":"1929","inReplyTo":"20050927094029.GA30889@pasky.or.cz","subject":"Re: Cogito: cg-clone doesn't like packed tag objects","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-09-27T17:07:38Z","receivedAt":"2005-09-27T17:07:38Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Petr Baudis <pasky@suse.cz> writes:\n\n> Yes, that's perhaps a fine solution for the core GIT plumbing, but in\n> Cogito, I _really_ want to have this working automagically.\n\nI agree that would be nice.  If you are only interested in tags\nthat refer to commits that anchor points in published branches,\nmaybe we should have something along the lines of info/refs to\nhelp the downloaders?  Perhaps info/refs showing the SHA1 id of\nthe non-tag object each tag dereferences to in addition to the\ncurrent output?\n\nThis is a bit hard and needs some thinking to do cleanly,\nbecause what is in info/refs is what is sent from the publisher\nside over git-native protocol at the beginning of the handshake,\nand it is not easy to add that to git-native protocol cleanly\nand backward-compatibly (I think I know how without breaking\nexisting clients, but it is not clean).\n"},{"id":"9402","messageId":"20050927173445.GC23034@mythryan2.michonline.com","threadId":"1929","inReplyTo":"Pine.LNX.4.58.0509270821590.3308@g5.osdl.org","subject":"Re: Cogito: cg-clone doesn't like packed tag objects","fromName":"Ryan Anderson","fromEmail":"ryan@michonline.com","sentAt":"2005-09-27T17:34:45Z","receivedAt":"2005-09-27T17:34:45Z","isPatch":false,"sender":{"key":"ryan@michonline.com","avatar":null},"body":"On Tue, Sep 27, 2005 at 08:34:22AM -0700, Linus Torvalds wrote:\n> On Tue, 27 Sep 2005, Ryan Anderson wrote:\n> > \n> > git-rev-parse $tagname^0\n> \n> You need \"--verify\". Otherwise git-rev-parse will think that you just have \n> a strange filename or other random thing:\n> \n> \tprompt$ git-rev-parse 000^0\n> \t000^0\n\nHmm:\n\n$ cat .git/refs/tags/v2.6.13-rc4\n7eab951de91d95875ba34ec4c599f37e1208db93\n$ git-rev-parse v2.6.13-rc4\n7eab951de91d95875ba34ec4c599f37e1208db93\n$ git-rev-parse v2.6.13-rc4^0\n63953523341bcafe5928bf6e99bffd7db94b471e\n$ git-rev-parse 63953523341bcafe5928bf6e99bffd7db94b471e^0\n63953523341bcafe5928bf6e99bffd7db94b471e\n\n# The typo that demonstrates what you did:\n$ git-rev-parse 7eab951de91d95875ba34ec4c599f37e1208db93^-\n7eab951de91d95875ba34ec4c599f37e1208db93^-\n\n$ git-rev-parse 7eab951de91d95875ba34ec4c599f37e1208db93^0\n63953523341bcafe5928bf6e99bffd7db94b471e\n\nSo I think --verify is beneficial if you want errors returned, but if\nyou know you have real tags or commits, git-rev-parse without the\n--verify seems to do the right thing.\n\nOr, at the very least, in the case where I used this\n(linux/scripts/setlocalversion), this behavior is fine.\n\n-- \n\nRyan Anderson\n  sometimes Pug Majere\n"},{"id":"9404","messageId":"Pine.LNX.4.58.0509271020530.3308@g5.osdl.org","threadId":"1929","inReplyTo":"7v64sm30dh.fsf@assigned-by-dhcp.cox.net","subject":"Re: Cogito: cg-clone doesn't like packed tag objects","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-09-27T17:56:24Z","receivedAt":"2005-09-27T17:56:24Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 27 Sep 2005, Junio C Hamano wrote:\n> \n> This is a bit hard and needs some thinking to do cleanly,\n> because what is in info/refs is what is sent from the publisher\n> side over git-native protocol at the beginning of the handshake,\n> and it is not easy to add that to git-native protocol cleanly\n> and backward-compatibly (I think I know how without breaking\n> existing clients, but it is not clean).\n\nArgh.\n\n\"git-upload-pack\" very much on purpose never sends partial object stores: \nit really doesn't want to send a tag-object for you to even _look_ at \nunless it also sends all the objects that you are missing that the tag \nrefers to.\n\nI'd really be much happier with the tag fetching being separate.\n\nFor example, making\n\n\tgit fetch --tags <dest>\n\nfetch all tags _and_ the objects that they depend on would seem a _lot_ \nmore appropriate.\n\nThe thing is, tags really may be totally private. For example, it makes \nsense to fetch tags when you pull an official tree (ie my kernel tree, or \nyour git tree), but it does NOT make sense for me to fetch tags \n(automatically or not) when I pull from a developers tree.\n\nThat's why git fetch doesn't get the tags by default. It's WRONG. \n\nBut we could certainly make it _easier_ to get tags when you want them. \n\"git-ls-remote\" already helps you, and\n\n\tgit-ls-remote ... | cut -f2 | grep '^refs/tags/'\n\ncompletes the picture. No protocol changes necessary, just some added \nmagic to git-fetch.sh.\n\nActually, here's a simple and stupid patch.\n\nUntested as usual, but hey, how hard can it be?\n\n\t\tLinus\n\n----\ndiff --git a/git-fetch.sh b/git-fetch.sh\n--- a/git-fetch.sh\n+++ b/git-fetch.sh\n@@ -5,6 +5,7 @@\n _x40='[0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f]'\n _x40=\"$_x40$_x40$_x40$_x40$_x40$_x40$_x40$_x40\"\n \n+tags=\n append=\n force=\n update_head_ok=\n@@ -17,6 +18,9 @@ do\n \t-f|--f|--fo|--for|--forc|--force)\n \t\tforce=t\n \t\t;;\n+\t--tags)\n+\t\ttags=t\n+\t\t;;\n \t-u|--u|--up|--upd|--upda|--updat|--update|--update-|--update-h|\\\n \t--update-he|--update-hea|--update-head|--update-head-|\\\n \t--update-head-o|--update-head-ok)\n@@ -151,7 +155,12 @@ case \"$update_head_ok\" in\n \t;;\n esac\n \n-for ref in $(get_remote_refs_for_fetch \"$@\")\n+taglist=\n+if [ \"$tags\" ]; then\n+\ttaglist=$(git-ls-remote \"$remote\" | awk '/refs\\/tags/ { print $2\":\"$2 }')\n+fi\n+\n+for ref in $(get_remote_refs_for_fetch \"$@\" $taglist)\n do\n     refs=\"$refs $ref\"\n \n"},{"id":"9405","messageId":"Pine.LNX.4.58.0509271058110.3308@g5.osdl.org","threadId":"1929","inReplyTo":"20050927173445.GC23034@mythryan2.michonline.com","subject":"Re: Cogito: cg-clone doesn't like packed tag objects","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-09-27T18:04:17Z","receivedAt":"2005-09-27T18:04:17Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 27 Sep 2005, Ryan Anderson wrote:\n> \n> $ cat .git/refs/tags/v2.6.13-rc4\n> 7eab951de91d95875ba34ec4c599f37e1208db93\n> $ git-rev-parse v2.6.13-rc4\n> 7eab951de91d95875ba34ec4c599f37e1208db93\n> $ git-rev-parse v2.6.13-rc4^0\n> 63953523341bcafe5928bf6e99bffd7db94b471e\n> $ git-rev-parse 63953523341bcafe5928bf6e99bffd7db94b471e^0\n> 63953523341bcafe5928bf6e99bffd7db94b471e\n\nThe point being that if you want to test whether you have the thing the \ntag _points_ to, you should verify it.\n\nAnd that's where the \"--verify\" flag comes in:\n\n\t[torvalds@g5 linux]$ git-rev-parse v2.6.11^0 ; echo $?\n\terror: Object 5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c is a tree, not a commit\n\tv2.6.11^0\n\t0\n\nand if the object the tag points to didn't exist at _all_ in your object\nstore, you'd have silently gotten\n\n\t[torvalds@g5 linux]$ git-rev-parse v2.6.11^0 ; echo $?\n        v2.6.11^0\n        0\n\nbut if you used \"--verify\", you'd have at least gotten\n\n\t[torvalds@g5 linux]$ git-rev-parse --verify v2.6.11^0 ; echo $?\n\tfatal: Needed a single revision\n\t1\n\nwhich is what you want, I thought.\n\n\t\tLinus\n"},{"id":"9406","messageId":"7v64sm1hp3.fsf@assigned-by-dhcp.cox.net","threadId":"1929","inReplyTo":"Pine.LNX.4.58.0509271020530.3308@g5.osdl.org","subject":"Re: Cogito: cg-clone doesn't like packed tag objects","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-09-27T18:36:24Z","receivedAt":"2005-09-27T18:36:24Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds <torvalds@osdl.org> writes:\n\n> On Tue, 27 Sep 2005, Junio C Hamano wrote:\n>> \n>> This is a bit hard and needs some thinking to do cleanly,\n>> because what is in info/refs is what is sent from the publisher\n>> side over git-native protocol at the beginning of the handshake,\n>> and it is not easy to add that to git-native protocol cleanly\n>> and backward-compatibly (I think I know how without breaking\n>> existing clients, but it is not clean).\n>\n> Argh.\n>\n> \"git-upload-pack\" very much on purpose never sends partial object stores: \n> it really doesn't want to send a tag-object for you to even _look_ at \n> unless it also sends all the objects that you are missing that the tag \n> refers to.\n>\n> I'd really be much happier with the tag fetching being separate.\n\nWhat Pasky wants to do, which I misunderstood first and gave\nessentially the same response to, is to help this senario:\n\n    User tracks git.git#master and nothing else, i.e. she pulls\n    from my master branch from time to time.  The tool notices\n    that I tagged a commit on the master branch (not necessarily\n    the tip at the time of pulling) with v0.99.8 tag, which she\n    has not have, and fetches v0.99.8 tag and stores it under\n    .git/refs/.  Currently Cogito does not let her specify\n    where on the receiving end to place that tag and always\n    places it in .git/refs/tags/v0.99.8, but that can be fixed\n    later.\n\nThe current ls-remote (or underlying fetch-pack protocol) does\nnot help this because the SHA1 given to Cogito is the object\nname of the tag, and without fetching the tag object and looking\nat what it refers to, Pasky cannot say \"Oh, this new v0.99.8 tag\nis the commit on the branch being tracked\".\n\nThe protocol extension I had in mind, which I said is not clean,\nis from upload_pack(), in addition to the existing send_ref()\ncall which sends \"object-name refname\" list like this:\n\n4899334e96a076bb8780968c5075b214aa80fab9\tHEAD\nd5bc7eecbbb0b9f6122708bf5cd62f78ebdaafd8\trefs/heads/maint\n3cc35e29ec252d0dca1139106fbaa70cb9ad6ef1\trefs/heads/master\n4899334e96a076bb8780968c5075b214aa80fab9\trefs/heads/pu\n348c4c66dacb1810a9bcd592e72f98a465233488\trefs/heads/rc\n0918385dbd9656cab0d1d81ba7453d49bbc16250\trefs/tags/junio-gpg-pub\nd6602ec5194c87b0fc87103ca4d67251c76f233a\trefs/tags/v0.99\nf25a265a342aed6041ab0cc484224d9ca54b6f41\trefs/tags/v0.99.1\n...\n\nwe could send phony entries like this:\n\nb92c9c07fe2d0d89c4f692573583c4753b5355d2\tderef/tags/junio-gpg-pub\na3eb250f996bf5e12376ec88622c4ccaabf20ea8\tderef/tags/v0.99\n78d9d414123ad6f4f522ffecbcd9e4a7562948fd\tderef/tags/v0.99.1\n\nThese phony entries tell the receiver what the tags eventually\nresolve to.  Pasky could use this to see if he has the named\nobject from the usual fetch path, and if he finds matches,\nask git-fetch-pack to get them.\n\nWe would need to teach git-clone and git-fetch to ignore deref/\nif they do not already do so.\n"},{"id":"9408","messageId":"Pine.LNX.4.58.0509271414000.3308@g5.osdl.org","threadId":"1929","inReplyTo":"7v64sm1hp3.fsf@assigned-by-dhcp.cox.net","subject":"Re: Cogito: cg-clone doesn't like packed tag objects","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-09-27T21:16:12Z","receivedAt":"2005-09-27T21:16:12Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 27 Sep 2005, Junio C Hamano wrote:\n> \n> The protocol extension I had in mind, which I said is not clean,\n> is from upload_pack(), in addition to the existing send_ref()\n> call which sends \"object-name refname\" list like this:\n> \n> 4899334e96a076bb8780968c5075b214aa80fab9\tHEAD\n...\n> \n> we could send phony entries like this:\n> \n> b92c9c07fe2d0d89c4f692573583c4753b5355d2\tderef/tags/junio-gpg-pub\n> a3eb250f996bf5e12376ec88622c4ccaabf20ea8\tderef/tags/v0.99\n> 78d9d414123ad6f4f522ffecbcd9e4a7562948fd\tderef/tags/v0.99.1\n\nYes, it would work, but I really think that there's no downside to just \nhaving a\n\n\tgit fetch --tags <dest>\n\nsince that's just a few lines of trivial code, with no special cases.\n\nOtherwise:\n\n> We would need to teach git-clone and git-fetch to ignore deref/\n> if they do not already do so.\n\nin general, it's just a really ugly special case, I think.\n\n\t\tLinus\n"},{"id":"9409","messageId":"Pine.LNX.4.58.0509271441210.3308@g5.osdl.org","threadId":"1929","inReplyTo":"Pine.LNX.4.58.0509271414000.3308@g5.osdl.org","subject":"Re: Cogito: cg-clone doesn't like packed tag objects","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-09-27T21:44:23Z","receivedAt":"2005-09-27T21:44:23Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 27 Sep 2005, Linus Torvalds wrote:\n> \n> Yes, it would work, but I really think that there's no downside to just \n> having a\n> \n> \tgit fetch --tags <dest>\n> \n> since that's just a few lines of trivial code, with no special cases.\n\nBtw, there are upsides too. Remember how confused people were about your\nvery own v0.99.7a-d releases? They are _not_ on your main path, so those\ntags wouldn't have been picked up even if Petr did his \"pick up tags to\nstuff you merge automatically\" thing.\n\nIn fact, if you'd add \"--tags\" as some kind of automated flag in the\n.git/remote/ file, then doing a \"git fetch origin\" could automatically \nfetch tags by default, _without_ having the mistake of fetching them in \ngeneral (it probably _does_ make sense to track tags from the origin, \nsince you get the ones the origin had at \"clone\" time anyway).\n\n\t\tLinus\n"},{"id":"9410","messageId":"7vll1iyxda.fsf@assigned-by-dhcp.cox.net","threadId":"1929","inReplyTo":"Pine.LNX.4.58.0509271414000.3308@g5.osdl.org","subject":"Re: Cogito: cg-clone doesn't like packed tag objects","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-09-27T22:11:29Z","receivedAt":"2005-09-27T22:11:29Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds <torvalds@osdl.org> writes:\n\n> Yes, it would work, but I really think that there's no downside to just \n> having a\n>\n> \tgit fetch --tags <dest>\n>\n> since that's just a few lines of trivial code, with no special cases.\n\nI do not oppose that idea.  I was just trying to point out that\n'git fetch --tags' does not solve what Pasky wants to do -- in\nhis ideal world, people track branches, and tags that refer to\nobjects that are on those tracked branches are automatically\nfetched; at the same time tags irrelevant to the tracked\nbranches are not fetched at all.  'git fetch --tags' would\nrequire the user to slurp in objects on branches she is not\ninterested in.\n"},{"id":"9434","messageId":"7virwlumyo.fsf@assigned-by-dhcp.cox.net","threadId":"1929","inReplyTo":"Pine.LNX.4.58.0509271414000.3308@g5.osdl.org","subject":"Re: Cogito: cg-clone doesn't like packed tag objects","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-09-28T17:22:07Z","receivedAt":"2005-09-28T17:22:07Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds <torvalds@osdl.org> writes:\n\n>> we could send phony entries like this:\n>> \n>> b92c9c07fe2d0d89c4f692573583c4753b5355d2\tderef/tags/junio-gpg-pub\n>> a3eb250f996bf5e12376ec88622c4ccaabf20ea8\tderef/tags/v0.99\n>> 78d9d414123ad6f4f522ffecbcd9e4a7562948fd\tderef/tags/v0.99.1\n>\n> Yes, it would work,..\n> in general, it's just a really ugly special case, I think.\n\nI think we could do this instead, to make it less ugly.\n\nb92c9c07fe2d0d89c4f692573583c4753b5355d2\trefs/tags/junio-gpg-pub!*\na3eb250f996bf5e12376ec88622c4ccaabf20ea8\trefs/tags/v0.99^0\n\nI am not sure what the syntax should be, but the idea is to\nexpress the \"refname\" side using \"extended SHA1\" syntax.  In the\nabove example, I added a postfix '!*' to mean \"deref tag\nzero-or-more times until you get a non-tag\" ('!' to mean deref\ntag once and complain if the object is not tag, '!!' is deref\ntwice, '!!!' is to deref three times and so on).  It might be\nbetter to spell \"v0.99^0\" as \"v0.99!*\" in this context. [*1*]\n\nBoth git-clone-pack and git-fetch-pack need to be told to ignore\nfunny tagnames with trailing '!*', otherwise they would ask for\nthe pointed-at object (which is not harmful but redundant) and\nthe clone would create \"refs/tags/v0.99!*\", a file with a funny\nname.  Git-peek-remote should report that, and server-info.c\nshould be told to prepare these extra entries for ls-remote over\nother protocols.\n\nBut I tend to agree that this is really a special case needed to\nsupport the \"tagged objects are automatically followed by tags\nthat tag them\" model, and not needed if we stay in \"tag is just\na ref, and a ref is just an object name, and asking for an\nobject pulls in other objects that are reachable from them\"\nmodel.  So it is not a very high priority for me, but I think\nthis is one way to help Cogito cleanly, and I am willing to see\nhow much damage this would cause to other parts of the core, *if*\nCogito wants to use this mechanism.\n\nThe alternative would be what Pasky outlined in his message --\nbypassing git transport layer to fetch single object by hand,\nrepeatedly dereferencing it until he gets a non-tag.  I think\nthat is unnecessary misery for him.\n\n\n[Footnote]\n\n*1* The difference from '^0' is that '!' does not complain on\nnon-commit, and can be used to peel the onion one layer at a\ntime.  I do not know how useful the latter is in practice but\nsomebody may want to express chains of trust by signing tags.\n"},{"id":"10094","messageId":"7voe5sws7y.fsf_-_@assigned-by-dhcp.cox.net","threadId":"1929","inReplyTo":"7virwlumyo.fsf@assigned-by-dhcp.cox.net","subject":"Peeling the onion","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-10-14T06:03:13Z","receivedAt":"2005-10-14T06:03:13Z","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> Linus Torvalds <torvalds@osdl.org> writes:\n>\n>>> we could send phony entries like this:\n>>> \n>>> b92c9c07fe2d0d89c4f692573583c4753b5355d2\tderef/tags/junio-gpg-pub\n>>> a3eb250f996bf5e12376ec88622c4ccaabf20ea8\tderef/tags/v0.99\n>>> 78d9d414123ad6f4f522ffecbcd9e4a7562948fd\tderef/tags/v0.99.1\n>>\n>> Yes, it would work,..\n>> in general, it's just a really ugly special case, I think.\n>\n> I think we could do this instead, to make it less ugly.\n>\n> ...\n>\n> The alternative would be what Pasky outlined in his message --\n> bypassing git transport layer to fetch single object by hand,\n> repeatedly dereferencing it until he gets a non-tag.  I think\n> that is unnecessary misery for him.\n\nI did not hear much from the people involved since this message,\nbut I have a bit less ugly solution along the lines outlined\nabove, in the proposed updates branch.  Incidentally this would\nalso simplify Martin's git-findtags, especially if we do not\nworry about its '-t' option.\n\nI'll be sending 3-patch series; the first two are preparatory\nbut what may be useful for Pasky and Martin is in the third\none.\n\n    [PATCH] Ignore funny refname sent from remote.\n    [PATCH] Introduce notation \"ref^{type}\".\n    [PATCH] Show peeled onion from upload-pack and server-info.\n"},{"id":"10096","messageId":"7vpsq8trsl.fsf@assigned-by-dhcp.cox.net","threadId":"1929","inReplyTo":"46a038f90510140048r30c7ec36n35f77a1ac52c4691@mail.gmail.com","subject":"Re: Peeling the onion","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-10-14T08:40:42Z","receivedAt":"2005-10-14T08:40:42Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Martin Langhoff <martin.langhoff@gmail.com> writes:\n\n> I personally don't care much for the -t option, at the moment. I do\n> think that tree identity is in some contexts more important than\n> commit identity, so there will be instances where you really want to\n> have a canonical way to \"drill down\" to the tree.\n\nI do not know how useful it would be, but the onion peeler can\nbe told to dereference commit to tree.\n\n$ ./git-cat-file -s 'v0.99.8^{tree}' \n6875\n$ ./git-cat-file -s 'v0.99.8^{commit}' \n435\n$ ./git-cat-file -t 'v0.99.8^{tree}' \ntree\n$ ./git-cat-file -t 'v0.99.8^{commit}' \ncommit\n$ ./git-rev-parse v0.99.8 \\\n  v0.99.8^0 v0.99.8^{commit} \\\n  v0.99.8^{commit}^{tree} v0.99.8^{tree}\nb041895af323bdef10cc9a718bda468ba3622bc0\n91dd674e30ba0298e89c9be2657024805170c2ac\n91dd674e30ba0298e89c9be2657024805170c2ac\nbfd844a69bfd582d107622c27b89e9b959e89fd8\nbfd844a69bfd582d107622c27b89e9b959e89fd8\n"},{"id":"11417","messageId":"20051109223303.GG30496@pasky.or.cz","threadId":"1929","inReplyTo":"7virwqwd3z.fsf@assigned-by-dhcp.cox.net","subject":"Re: Cogito: cg-clone doesn't like packed tag objects","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-11-09T22:33:04Z","receivedAt":"2005-11-09T22:33:04Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Sat, Sep 24, 2005 at 08:10:40PM CEST, I got a letter\nwhere Junio C Hamano <junkio@cox.net> told me that...\n> > default post-update hook could change to\n> >\n> > \t[ -e \"$_git/git-dummy-support\" ] && exec git-update-server-info\n> >\n> > and be enabled by default?\n> \n> That is a thought.  While I think doing update-server-info\n> everywhere whenever you update ref is going a bit overboard, I\n> agree there should be an easy way for the end user to keep\n> repositories that are public accessible all times.  But running\n> server-info upon every commit does not make much sense to me --\n> something is seriously broken if we need to do that.\n\nPoint taken, you are right.\n\nBTW, Cogito has for a while the command 'cg-admin-setuprepo' which is\ndesigned to be used to create those public accessible repositories where\nyou typically only push to. Recently, I've also changed it so that it\njust enables the default post-update hook; is it safe to assume that the\ndefault template post-update hook shipped with GIT will be\ngood-to-be-autoenabled on public repositories and will always contain\nthe git-update-server-info invocation (unless it becomes irrelevant in\nthe future) ?\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nVI has two modes: the one in which it beeps and the one in which\nit doesn't.\n"},{"id":"11425","messageId":"7v3bm59zxu.fsf@assigned-by-dhcp.cox.net","threadId":"1929","inReplyTo":"20051109223303.GG30496@pasky.or.cz","subject":"Re: Cogito: cg-clone doesn't like packed tag objects","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-11-09T23:14:21Z","receivedAt":"2005-11-09T23:14:21Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Petr Baudis <pasky@suse.cz> writes:\n\n> ...; is it safe to assume that the\n> default template post-update hook shipped with GIT will be\n> good-to-be-autoenabled on public repositories \n\nI do not think that is an unreasonable assumption.  After all,\nsample hooks are there to help people setting up common usage\npatterns, not to show off flashy but irrelevant-to-the-real-world-needs\nfeatures ;-).\n\nPlease yell loudly when somebody posts a patch or brings up a\nproposal to break that assumption in the future.\n"},{"id":"11433","messageId":"20051109233614.GA4051@reactrix.com","threadId":"1929","inReplyTo":"7v3bm59zxu.fsf@assigned-by-dhcp.cox.net","subject":"Re: Cogito: cg-clone doesn't like packed tag objects","fromName":"Nick Hengeveld","fromEmail":"nickh@reactrix.com","sentAt":"2005-11-09T23:36:14Z","receivedAt":"2005-11-09T23:36:14Z","isPatch":false,"sender":{"key":"nickh@reactrix.com","avatar":null},"body":"On Wed, Nov 09, 2005 at 03:14:21PM -0800, Junio C Hamano wrote:\n\n> > ...; is it safe to assume that the\n> > default template post-update hook shipped with GIT will be\n> > good-to-be-autoenabled on public repositories \n> \n> Please yell loudly when somebody posts a patch or brings up a\n> proposal to break that assumption in the future.\n\nWouldn't this be a problem on public repositories that are hosted with\nDAV?\n\n-- \nFor a successful technology, reality must take precedence over public\nrelations, for nature cannot be fooled.\n"},{"id":"11435","messageId":"20051109234405.GK30496@pasky.or.cz","threadId":"1929","inReplyTo":"20051109233614.GA4051@reactrix.com","subject":"Re: Cogito: cg-clone doesn't like packed tag objects","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-11-09T23:44:05Z","receivedAt":"2005-11-09T23:44:05Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Thu, Nov 10, 2005 at 12:36:14AM CET, I got a letter\nwhere Nick Hengeveld <nickh@reactrix.com> said that...\n> Wouldn't this be a problem on public repositories that are hosted with\n> DAV?\n\nHmm. Yes, that's bad. Couldn't the HTTP pusher actually get the current\nserver info, update it at the pusher's side and send it back?\n\nAnd add a warning to some documentation that HTTP push won't trigger the\nupdate hooks.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nVI has two modes: the one in which it beeps and the one in which\nit doesn't.\n"},{"id":"11437","messageId":"7vek5p8juq.fsf@assigned-by-dhcp.cox.net","threadId":"1929","inReplyTo":"20051109233614.GA4051@reactrix.com","subject":"Re: Cogito: cg-clone doesn't like packed tag objects","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-11-09T23:47:09Z","receivedAt":"2005-11-09T23:47:09Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nick Hengeveld <nickh@reactrix.com> writes:\n\n> On Wed, Nov 09, 2005 at 03:14:21PM -0800, Junio C Hamano wrote:\n>\n>> > ...; is it safe to assume that the\n>> > default template post-update hook shipped with GIT will be\n>> > good-to-be-autoenabled on public repositories \n>> \n>> Please yell loudly when somebody posts a patch or brings up a\n>> proposal to break that assumption in the future.\n>\n> Wouldn't this be a problem on public repositories that are hosted with\n> DAV?\n\nNot unless you arrange the DAV server to honor hooks. ;-).\n\nIOW, yeah, there may be problems.\n"},{"id":"11448","messageId":"20051110010146.GC4051@reactrix.com","threadId":"1929","inReplyTo":"20051109234405.GK30496@pasky.or.cz","subject":"Re: Cogito: cg-clone doesn't like packed tag objects","fromName":"Nick Hengeveld","fromEmail":"nickh@reactrix.com","sentAt":"2005-11-10T01:01:46Z","receivedAt":"2005-11-10T01:01:46Z","isPatch":false,"sender":{"key":"nickh@reactrix.com","avatar":null},"body":"On Thu, Nov 10, 2005 at 12:44:05AM +0100, Petr Baudis wrote:\n\n> Hmm. Yes, that's bad. Couldn't the HTTP pusher actually get the current\n> server info, update it at the pusher's side and send it back?\n\nYes, although duplicating all of what update-server-info does is going\nto take a while...\n\nHowever, the only thing of interest to update-server-info that http-push\nis able to change is a ref.  It would be much more straightforward to\nlock and update info/refs after a successful push; is that good enough?\nThe same thing could apply to objects/info/packs if/when http-push\nstarts sending packs.\n\n-- \nFor a successful technology, reality must take precedence over public\nrelations, for nature cannot be fooled.\n"}]}