{"thread":{"id":"1916","subject":"Re: Please undo \"Use git-merge instead of git-resolve in","startedAt":"2005-09-22T18:32:45Z","lastAt":"2005-09-24T06:19:01Z","messageCount":11,"participants":["Jon Loeliger","Petr Baudis","Sean","Linus Torvalds","Junio C Hamano","Daniel Barkalow"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"9129","messageId":"E1EIVsD-0001Hu-9m@jdl.com","threadId":"1916","inReplyTo":null,"subject":"Re: Please undo \"Use git-merge instead of git-resolve in","fromName":"Jon Loeliger","fromEmail":"jdl@freescale.com","sentAt":"2005-09-22T18:32:45Z","receivedAt":"2005-09-22T18:32:45Z","isPatch":false,"sender":{"key":"jdl@jdl.com","avatar":"https://gravatar.com/avatar/75ce9a10b151acd2c28ec4ab2136dba7b2ff1634530bd04b155981a749d08a64?d=mp&s=160"},"body":"Linus schreib:\n>\n>\tgit fetch rsync:..../linus-2.6-git :\n>\n> will fetch the branch (ie you'd usually use \"master\") from my tree \n> and write it to the branch on your tree.\n\n... \"origin\". OK.\n\nUnd, Petr schreib auch:\n> Then it creates an 'origin' head, and will copy all the history from\n> the remote repository's 'master' head there. So this head exists to\n> reflect the state of the remote repository. The important point is\n> that it is called 'origin' in our new repository, even through it\n> corresponds to a 'master' head in the old repository. This is normal -\n> you can name your local heads whatever you want.\n\nWait.\n\nFor me, this paragraph suddenly turned on one missing light:\nThe default construction of repository branches/heads _mismatches_\nnames on local and remote ends: \"origin\" local came from \"master\"\nremote. Did I miss reading that somewhere else? (Likely.)\n\nAnd I sat through the Great Remote Name Discussion of '05\n(\"How is working on arbitrary remote heads supposed to work in Cogito\")\nbut I just didn't get it back then.\n\n(This is an intentional asymmetry, right? Distributed systems, right?)\n\nIn any case, I just tried this:\n\n git fetch rsync://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.gi\\t master:origin\n\nAnd got this mess:\n\n sent 18136 bytes received 2731519 bytes 60431.98 bytes/sec\n total size is 97584183 speedup is 35.49\n rsync: link_stat \"/scm/linux/kernel/git/torvalds/linux-2.6.git/objects/info/alt\\ernates\" (in pub) failed: No such file or directory (2)\n rsync error: some files could not be transferred (code 23) at main.c(1173)\n * non-commit: 3fd07d3bf0077dcc0f5a33d2eb1938ea050da8da\n branch 'master' of rsync://www.kernel.org/pub/scm/linux/kernel/git/torvalds/l\\inux-2.6\n * refs/heads/origin: does not fast forward to branch 'master' of rsync://www.ke\\rnel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6;\n leaving it in 'refs/heads/origin.remote'\n\nAnd this is due to kernel.org being Not Quite Right, right?\n\nWhich points out one of the other points of frustration\nthat I feel should be addressed eventually: A whole section\nabout \"What To Do When It Goes Wonky\" needs to be written.\n\nOK, so it didn't merge? Now what? What got left where?\nHow do I recover? What bits are in my tree, and what bits\nare in the Index, and what bits are in the Object store now?\n\nOK, so it didn't download it left you \"refs/heads/rigin.remote\".\nWhat should I do with it now? And later, should I re-execute\nthe same \"git fetch\" command and hope it recovers and patches\nthe pieces together? Should I do a round of house cleaning\nbefore attempting to re-run some (the same?) command?\n\nThings of that nature.\n\nAnd more as I get further too. :-)\n\nThanks!\njdl\n"},{"id":"9130","messageId":"20050922191058.GM21019@pasky.or.cz","threadId":"1916","inReplyTo":"E1EIVsD-0001Hu-9m@jdl.com","subject":"Re: Please undo \"Use git-merge instead of git-resolve in","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-09-22T19:10:58Z","receivedAt":"2005-09-22T19:10:58Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Thu, Sep 22, 2005 at 08:32:45PM CEST, I got a letter\nwhere Jon Loeliger told me that...\n> Which points out one of the other points of frustration\n> that I feel should be addressed eventually: A whole section\n> about \"What To Do When It Goes Wonky\" needs to be written.\n> \n> OK, so it didn't merge? Now what? What got left where?\n> How do I recover? What bits are in my tree, and what bits\n> are in the Index, and what bits are in the Object store now?\n> \n> OK, so it didn't download it left you \"refs/heads/rigin.remote\".\n> What should I do with it now? And later, should I re-execute\n> the same \"git fetch\" command and hope it recovers and patches\n> the pieces together? Should I do a round of house cleaning\n> before attempting to re-run some (the same?) command?\n\nFWIW, with Cogito, interrupted or failed fetch can be safely rerun, no\nextra recovery procedure is required. It *seems* that this holds for\ngit-fetch as well.\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":"9133","messageId":"BAYC1-PASMTP0510EEC44C7F787F27215AAE970@CEZ.ICE","threadId":"1916","inReplyTo":"20050922191058.GM21019@pasky.or.cz","subject":"Re: Please undo \"Use git-merge instead of git-resolve in","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2005-09-22T19:25:34Z","receivedAt":"2005-09-22T19:25:34Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Thu, September 22, 2005 3:10 pm, Petr Baudis said:\n\n> FWIW, with Cogito, interrupted or failed fetch can be safely rerun, no\n> extra recovery procedure is required. It *seems* that this holds for\n> git-fetch as well.\n\nPetr,\n\nWhy doesn't cogito just use the git fetch/pull commands? Why does it\nneed anything special? It seems like cogito is doing more than just\nbeing an ease-of-use layer above git.\n\nSean\n"},{"id":"9135","messageId":"Pine.LNX.4.58.0509221355330.2553@g5.osdl.org","threadId":"1916","inReplyTo":"E1EIVsD-0001Hu-9m@jdl.com","subject":"Re: Please undo \"Use git-merge instead of git-resolve in","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-09-22T21:12:38Z","receivedAt":"2005-09-22T21:12:38Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 22 Sep 2005, Jon Loeliger wrote:\n> \n> For me, this paragraph suddenly turned on one missing light:\n> The default construction of repository branches/heads _mismatches_\n> names on local and remote ends: \"origin\" local came from \"master\"\n> remote. Did I miss reading that somewhere else? (Likely.)\n> \n> And I sat through the Great Remote Name Discussion of '05\n> (\"How is working on arbitrary remote heads supposed to work in Cogito\")\n> but I just didn't get it back then.\n> \n> (This is an intentional asymmetry, right? Distributed systems, right?)\n\nRight. It's intentional. The \"master\" branch tends to be the main one for\neverybody, but _my_ \"master\" branch is clearly _your_ \"linus\" branch, and\n_your_ \"master\" branch would be the \"jon\" branch for me.\n\nSo it's not \"asymmetric\". It _is_ symmetric, but it's symmetric the same\nway \"left\" and \"right\" are symmetric when facing each other - my left is\nyour right, your left is my right. It's a symmetry, but it's not an \n_identity_.\n\nAnd obviously, nobody is going to have every possible branch anyway. You\njust name the ones you care about (and that, in turn, _will_ break the\nsymmetry ;)\n\n> In any case, I just tried this:\n> \n> git fetch rsync://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git master:origin\n> \n> And got this mess:\n> \n> sent 18136 bytes received 2731519 bytes 60431.98 bytes/sec\n> total size is 97584183 speedup is 35.49\n> rsync: link_stat \"/scm/linux/kernel/git/torvalds/linux-2.6.git/objects/info/alternates\" (in pub) failed: No such file or directory (2)\n> rsync error: some files could not be transferred (code 23) at main.c(1173)\n\nOk, ignore that error.\n\n> * non-commit: 3fd07d3bf0077dcc0f5a33d2eb1938ea050da8da\n> branch 'master' of rsync://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6\n\nOk, 3fd07d3bf0077dcc0f5a33d2eb1938ea050da8da is my current head, so that \npart looks good. However, the \"non-commit\" part doesn't look good. It \n_should_ say \"committish\".\n\nWhat does\n\n\tgit-cat-file -t 3fd07d3bf0077dcc0f5a33d2eb1938ea050da8da\n\nsay in your tree? I suspect you don't have that object at all, and that\nthe mirrors are still not in sync (ie I suspect you get a \"error: unable\nto find 3fd..\")\n\nThis, btw, is why I hate the rsync protocol. Quite frankly, it sucks. It\nwas wonderful for bootstrapping git when we didn't have anything else, but\ndammit, it's horrid. It has no git knowledge at all, does _zero_ sanity\nchecking, and leaves the user going \"huh\" when it fails.\n\n> * refs/heads/origin: does not fast forward to branch 'master' of rsync://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6;\n> leaving it in 'refs/heads/origin.remote'\n> \n> And this is due to kernel.org being Not Quite Right, right?\n\nYes. It tries to verify that the new commit it stuffs into \"origin\" is a \nproper superset of the old one (so that you're not losing any data), and \nit fails, since the new commit doesn't even exist in your object list yet.\n\n> Which points out one of the other points of frustration\n> that I feel should be addressed eventually: A whole section\n> about \"What To Do When It Goes Wonky\" needs to be written.\n\nHey, you seem to have a good example of Wonky, maybe you want to write it?\n\n> OK, so it didn't merge? Now what? What got left where?\n> How do I recover? What bits are in my tree, and what bits\n> are in the Index, and what bits are in the Object store now?\n\nThe good news is, I don't think there's anything to recover. It refused to \nwrite the new head, because it wasn't valid yet.\n\nActually, the fact that it even left it as a head might cause problems \n(because now you have a reference to something that doesn't exist), so you \nare probably best off just removing the .git/refs/heads/origin.remote file \nentirely. \n\nYou just need to try again when the mirroring is doing better.\n\nOh. And I think you might want to change that \"rsync:\" to \"http:\" instead. \nIt's going to be slower, but at least git-http-fetch should be more \ncareful, since it's fetching one object at a time, and validating what it \nfetches that way. The rsync: protocol just does everything totally blidly \n(which makes it fairly efficient, but also means that when things go \nwrong, they are _really_ confusing).\n\n\t\tLinus\n"},{"id":"9143","messageId":"7vk6h8lp3k.fsf@assigned-by-dhcp.cox.net","threadId":"1916","inReplyTo":"BAYC1-PASMTP0510EEC44C7F787F27215AAE970@CEZ.ICE","subject":"Re: Please undo \"Use git-merge instead of git-resolve in","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-09-22T22:22:39Z","receivedAt":"2005-09-22T22:22:39Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Sean\" writes:\n\n> Why doesn't cogito just use the git fetch/pull commands? Why does it\n> need anything special? It seems like cogito is doing more than just\n> being an ease-of-use layer above git.\n\nThe way this question is posed is quite unfair to Pasky -- it\nmakes him look needlessly bad.\n\nThe simple reason is because Cogito had its own richer\nfetch/pull first. The development of git aware pack transfer\nprotocols by Linus and the list discussion for multi-head pushes\nand pulls came much later, which resulted in the current 'git\nfetch/pull' interface.\n"},{"id":"9144","messageId":"BAYC1-PASMTP0529AB50E9E3F8BACFE1EFAE970@CEZ.ICE","threadId":"1916","inReplyTo":"7vk6h8lp3k.fsf@assigned-by-dhcp.cox.net","subject":"Re: Please undo \"Use git-merge instead of git-resolve in","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2005-09-22T22:54:34Z","receivedAt":"2005-09-22T22:54:34Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Thu, September 22, 2005 6:22 pm, Junio C Hamano said:\n> \"Sean\" writes:\n>\n>> Why doesn't cogito just use the git fetch/pull commands? Why does it\n>> need anything special? It seems like cogito is doing more than just\n>> being an ease-of-use layer above git.\n>\n> The way this question is posed is quite unfair to Pasky -- it\n> makes him look needlessly bad.\n\nWill try to pose it differently then, because it was not meant to make him\n\"look bad\". In a different email Pasky seemed to be musing that cogito\nmight do away with fast forward merges. This too seemed like a decision\nbest left to the plumbing, so i have been wondering how Pasky views\ncogito's relationship to git.\n\nBut the immediate question really was, wouldn't it be better if cogito\nused the same code paths that git uses for push/pull/fetch? Is there a\nreason that this isn't possible?\n\n> The simple reason is because Cogito had its own richer\n> fetch/pull first. The development of git aware pack transfer\n> protocols by Linus and the list discussion for multi-head pushes\n> and pulls came much later, which resulted in the current 'git\n> fetch/pull' interface.\n\nYes, cogito had it first but once this functionality gets pushed down into\ngit (where it's been for a while now) it makes a lot of sense for the\nprocelain layers to use it. That way the functionality only has to be\nmaintained in one place and nobody has to guess what transports work with\ncogito or git etc. But perhaps there are reasons that this just isn't\npossible with the cogito code, i dunno.\n\nSean\n"},{"id":"9161","messageId":"20050923091012.GA10255@pasky.or.cz","threadId":"1916","inReplyTo":"34462.10.10.10.28.1127417134.squirrel@linux1","subject":"Re: Please undo \"Use git-merge instead of git-resolve in","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-09-23T09:10:12Z","receivedAt":"2005-09-23T09:10:12Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Thu, Sep 22, 2005 at 09:25:34PM CEST, I got a letter\nwhere Sean told me that...\n> On Thu, September 22, 2005 3:10 pm, Petr Baudis said:\n> \n> > FWIW, with Cogito, interrupted or failed fetch can be safely rerun, no\n> > extra recovery procedure is required. It *seems* that this holds for\n> > git-fetch as well.\n> \n> Petr,\n> \n> Why doesn't cogito just use the git fetch/pull commands? Why does it\n> need anything special? It seems like cogito is doing more than just\n> being an ease-of-use layer above git.\n\nAs Junio already explained, Cogito had those commands earlier - so the\nmain reason was simply that I didn't manage to do it yet. It is not so\neasy to keep up with the latest GIT stuff _and_ enhance Cogito at the\nsame time, so I simply didn't get to really consider that yet. :-)\n\nThat said, this is a non-comprehensive list of the factors in my\nconsideration:\n\nPros (not so much of them, but they are big):\n\t* Already supports alternates and remotes\n\t* Do it once, stop caring :-) - only single instance of the code\n\t does the stuff (this is obviously the motivation)\n\nCons:\n\t* cg-fetch can do with symlinked object database\n\t* cg-fetch will hardlink if possible when fetching locally\n\t* cg-fetch will fetch the tags if possible\n\t\t(this is actually a bit controversial - we should have\n\t\tthe private/public tags distinction, that's another\n\t\tthing I simply didn't get to yet)\n\t* cg-fetch has cute progress info\n\t\t(perhaps git-fetch output could be just fed to that)\n\t* cg-fetch won't do useless fetches when we are already\n\t up-to-date\n\t* I'm not sure if I could call git-fetch to do the initial\n\t fetch during clone\n\t* The amount of work to initially convert it might be comparable\n\t with implementing the current new stuff\n\t* I really dislike the git-fetch coding style\n\t\tThis is not that I'd like to force my coding style\n\t\tcustoms on anyone and Junio might well feel the same\n\t\tabout Cogito's code, but I would have to support and\n\t\tfix bugs in git-fetch if I used it.\n\t* I'm obviously not too happy to throw away the rather big\n\t amount of code I spent a lot of time on and which is already\n\t pretty well debugged and tuned, I think (that's not to say\n\t that git-fetch is buggy... ;-)\n\nThe cons may seem mostly minor stuff which is quite fixable, and that's\nright, it's just show that there is plenty of stuff to do before\ngit-fetch will be superset of cg-fetch. Now because of the coding style,\nI might as well just implement the alternates and remotes stuff to\ncg-fetch, which would be less work and less painful for me in the short\nterm.\n\nI'll convert cg-object-id to use git-rev-parse after the release so that\nyou can't say I'm an old-fashioned freak refusing to use any of the new\nGIT stuff. :^)\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":"9165","messageId":"7vslvwcelj.fsf@assigned-by-dhcp.cox.net","threadId":"1916","inReplyTo":"20050923091012.GA10255@pasky.or.cz","subject":"Re: Please undo \"Use git-merge instead of git-resolve in","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-09-23T09:34:16Z","receivedAt":"2005-09-23T09:34:16Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Petr Baudis writes:\n\n> \t* cg-fetch can do with symlinked object database\n\nDo you mean \".git/object\" in the repository you are fetching\ninto is a symlink to somewhere, or something else?\n\n> \t* cg-fetch will hardlink if possible when fetching locally\n\nTrue, git-fetch and git-clone try to use pack protocols by\ndefault, which is debatable. Adding -l (similar to what\ngit-clone does) would not be too hard, if enough people want\nit.\n\n> \t* cg-fetch won't do useless fetches when we are already\n> \t up-to-date\n\nCare to explain? Perhaps you are talking about rsync transport\n(in which case I would not be surprised)?\n\n> \t* I'm not sure if I could call git-fetch to do the initial\n> \t fetch during clone\n\n $ git-init-db && git fetch http://kernel.org/pub/scm/git/git.git\n\nshould work.\n\nThere is another minor \"con\", if you include git-clone in the\ndiscussion. Over http transport, it refuses to run against a\nremote repository that does not have info/refs and info/packs,\neven if it is not packed. I think cg-clone uses recursive wget\nfor directory traversal and does not have to use them.\n"},{"id":"9167","messageId":"20050923095742.GC10255@pasky.or.cz","threadId":"1916","inReplyTo":"7vslvwcelj.fsf@assigned-by-dhcp.cox.net","subject":"Re: Please undo \"Use git-merge instead of git-resolve in","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-09-23T09:57:42Z","receivedAt":"2005-09-23T09:57:42Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Fri, Sep 23, 2005 at 11:34:16AM CEST, I got a letter\nwhere Junio C Hamano told me that...\n> Petr Baudis writes:\n> \n> > \t* cg-fetch can do with symlinked object database\n> \n> Do you mean \".git/object\" in the repository you are fetching\n> into is a symlink to somewhere, or something else?\n\nYes, exactly that. You get it by doing cg-clone -l /local/path. O(1)\ncloning, but it has its downsides and dangers which I tried to describe\nin the cg-clone documentation.\n\n> > \t* cg-fetch won't do useless fetches when we are already\n> > \t up-to-date\n> \n> Care to explain? Perhaps you are talking about rsync transport\n> (in which case I would not be surprised)?\n\nJust that if the reference pointer did not change, you don't try to pull\nany objects. Speeds things up somewhat, and now it should always work\n(well, cg-fetch has -f which makes it always try objects as well, in\ncase something went wrong anyway).\n\n> > \t* I'm not sure if I could call git-fetch to do the initial\n> > \t fetch during clone\n> \n> $ git-init-db && git fetch http://kernel.org/pub/scm/git/git.git\n> \n> should work.\n\nGood.\n\n> There is another minor \"con\", if you include git-clone in the\n> discussion. Over http transport, it refuses to run against a\n> remote repository that does not have info/refs and info/packs,\n> even if it is not packed. I think cg-clone uses recursive wget\n> for directory traversal and does not have to use them.\n\ncg-clone just basically does cg-init && cg-fetch, and I'd really want to\nkeep it on that. So effectively, cg-clone over http just runs\ngit-http-fetch and trusts it to do the right thing (reasonably fast).\n\nRecursive wget is used only for fetching tags (and it actually seems to\nwork nicely, when directory listing is enabled, obviously). Yes, I\nshould teach cg-fetch about info/refs too.\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":"9198","messageId":"Pine.LNX.4.63.0509231648310.23242@iabervon.org","threadId":"1916","inReplyTo":"20050923095742.GC10255@pasky.or.cz","subject":"Re: Please undo \"Use git-merge instead of git-resolve in","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2005-09-23T21:07:37Z","receivedAt":"2005-09-23T21:07:37Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Fri, 23 Sep 2005, Petr Baudis wrote:\n\n> Dear diary, on Fri, Sep 23, 2005 at 11:34:16AM CEST, I got a letter\n> where Junio C Hamano told me that...\n> > Petr Baudis writes:\n> > \n> > > \t* cg-fetch can do with symlinked object database\n> > \n> > Do you mean \".git/object\" in the repository you are fetching\n> > into is a symlink to somewhere, or something else?\n> \n> Yes, exactly that. You get it by doing cg-clone -l /local/path. O(1)\n> cloning, but it has its downsides and dangers which I tried to describe\n> in the cg-clone documentation.\n\nThat's actually how I use git, and it works for me. (To be precise, I \nhave:\n\n ~/git/project.git/{objects,refs,info}\n\nand I have\n\n ~/working/git/current-work/, with .git/{objects,refs,info} symlinks to \n the above.\n\ngit fetch works fine, with the exception that remotes aren't shared \nbetween working trees.\n\n> > > \t* cg-fetch won't do useless fetches when we are already\n> > > \t up-to-date\n> > \n> > Care to explain? Perhaps you are talking about rsync transport\n> > (in which case I would not be surprised)?\n> \n> Just that if the reference pointer did not change, you don't try to pull\n> any objects. Speeds things up somewhat, and now it should always work\n> (well, cg-fetch has -f which makes it always try objects as well, in\n> case something went wrong anyway).\n\nI assume you mean with rsync? The current git-http-fetch won't try any \nobjects if the ref didn't change (or, for that matter, if we have a \ndifferent ref that's the same), and the old one would make a local check \nfor the objects before trying to downlaod anything.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"9222","messageId":"7virwr2dka.fsf@assigned-by-dhcp.cox.net","threadId":"1916","inReplyTo":"20050923095742.GC10255@pasky.or.cz","subject":"Re: Please undo \"Use git-merge instead of git-resolve in","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-09-24T06:19:01Z","receivedAt":"2005-09-24T06:19:01Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Petr Baudis writes:\n\n> Dear diary, on Fri, Sep 23, 2005 at 11:34:16AM CEST, I got a letter\n> where Junio C Hamano told me that...\n>> Petr Baudis writes:\n>> \n>> > \t* cg-fetch can do with symlinked object database\n>> \n>> Do you mean \".git/object\" in the repository you are fetching\n>> into is a symlink to somewhere, or something else?\n>\n> Yes, exactly that. You get it by doing cg-clone -l\n> /local/path.\n\ngit-clone -l -s does optimization similar to that in spirit, but\nit does not create a repository with symlinked .git/object\npointing at /some/where/original/repo/.git/object. Instead it\nuses alternates to borrow from the other; newly created objects\nare always stored locally.\n\nBut I thought you were talking about fetch. git-fetch should be\nable to pull into a repository whose .git/object happens to be a\nsymlink pointing at somewhere else just fine.\n\n> Just that if the reference pointer did not change, you don't try to pull\n> any objects.\n\nBoth git-aware protocol and commit walker peek at the remote ref\nand stop without downloading objects if it is known to us, so I\nthink we are OK.\n\n>> $ git-init-db && git fetch http://kernel.org/pub/scm/git/git.git\n>> \n>> should work.\n>\n> Good.\n\nOf course, the above 'git fetch' only fetches remote HEAD and\nstores it in .git/FETCH_HEAD; if you truly want to 'clone', you\ncould first run git-ls-remote to peek the remote refs and then\ngive them as storing refspecs to git fetch, doing something like\nthis (modulo renaming 'master' over there to 'origin' here):\n\n\tmkdir foo && cd foo && git-init-db\n\trefspec=$(git-ls-remote $repo | \\\n\t sed -n -e 's/^[0-9a-f]*\t//' -e 's|refs/.*|&:&|p')\n\tgit fetch $repo $refspec\n"}]}