{"thread":{"id":"43267","subject":"Re: git fetch --reference?","startedAt":"2006-11-15T00:38:26Z","lastAt":"2006-11-15T01:49:58Z","messageCount":5,"participants":["Junio C Hamano","Michael K. Edwards","Jakub Narebski"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"297011","messageId":"f2b55d220611141638k5f4a0aeas1a43301e4b40bf59@mail.gmail.com","threadId":"43267","inReplyTo":null,"subject":"git fetch --reference?","fromName":"Michael K. Edwards","fromEmail":"medwards.linux@gmail.com","sentAt":"2006-11-15T00:38:26Z","receivedAt":"2006-11-15T00:38:26Z","isPatch":false,"sender":{"key":"medwards.linux@gmail.com","avatar":null},"body":"When setting up a working area for kernel integration for a new\nembedded target, I generally do a \"git clone --reference\" so that the\nnew area has its own repository (and its own branch structure) but\nmost of the blobs come from a local reference copy. But now that I'm\nintegrating bits from several non-trivially divergent trees (mtd-2.6,\nnetdev-2.6, linux-2.6.16.y, etc.), it would be nice to avoid\nre-downloading blobs for these additional remote branches, which are\nalso available in the local reference copy. Is it feasible to\nimplement \"git fetch --reference\" for this purpose? Or is there a\nbetter way to manage this sort of integration effort?\n\nCheers,\n"},{"id":"294185","messageId":"7vy7qdttc0.fsf@assigned-by-dhcp.cox.net","threadId":"43267","inReplyTo":"f2b55d220611141638k5f4a0aeas1a43301e4b40bf59@mail.gmail.com","subject":"Re: git fetch --reference?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-15T01:02:55Z","receivedAt":"2006-11-15T01:02:55Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Michael K. Edwards\" writes:\n\n> When setting up a working area for kernel integration for a new\n> embedded target, I generally do a \"git clone --reference\" so that the\n> new area has its own repository (and its own branch structure) but\n> most of the blobs come from a local reference copy. But now that I'm\n> integrating bits from several non-trivially divergent trees (mtd-2.6,\n> netdev-2.6, linux-2.6.16.y, etc.), it would be nice to avoid\n> re-downloading blobs for these additional remote branches, which are\n> also available in the local reference copy. Is it feasible to\n> implement \"git fetch --reference\" for this purpose? Or is there a\n> better way to manage this sort of integration effort?\n\nI am somewhat doubtful that this is common enough to warrant\nadding an extra option to \"git fetch\", but you could add\nalternates to these new reference object stores before\ninitiating the fetch.\n\nFor example, if you have pristine linux-2.6/ and your work was\nstarted by cloning with --reference to it into my-2.6/, you\nwould have something like this:\n\n\t$ cd /usr/src\n\t$ ls -F\n linux-2.6/ linux-2.6.16.y/ netdev-2.6/ my-2.6/\n\t$ cd my-2.6/\n $ cat .git/objects/info/alternates\n\t/usr/src/linux-2.6/.git/objects\n\nThen you would (still in my-2.6 repository):\n\n\t$ cat >>.git/objects/info/alternates\n /usr/src/linux-2.6.16.y/.git/objects\n /usr/src/netdev-2.6/.git/objects\n $ git pull ../netdev-2.6/ ALL\n\nwhich would hopefully not download _any_ objects but just gets\nthe ALL branch and makes a merge commit in your working\nrepository.\n\n \n"},{"id":"298245","messageId":"ejdovj$drm$1@sea.gmane.org","threadId":"43267","inReplyTo":"f2b55d220611141638k5f4a0aeas1a43301e4b40bf59@mail.gmail.com","subject":"Re: git fetch --reference?","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-11-15T01:04:00Z","receivedAt":"2006-11-15T01:04:00Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Michael K. Edwards wrote:\n\n> When setting up a working area for kernel integration for a new\n> embedded target, I generally do a \"git clone --reference\" so that the\n> new area has its own repository (and its own branch structure) but\n> most of the blobs come from a local reference copy. But now that I'm\n> integrating bits from several non-trivially divergent trees (mtd-2.6,\n> netdev-2.6, linux-2.6.16.y, etc.), it would be nice to avoid\n> re-downloading blobs for these additional remote branches, which are\n> also available in the local reference copy. Is it feasible to\n> implement \"git fetch --reference\" for this purpose? Or is there a\n> better way to manage this sort of integration effort?\n\nAll (I think) that --reference does is to create alternates file.\nYou can simply add another alternate before fetch.\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"298323","messageId":"f2b55d220611141717r4507c9demddb1cf872dbee073@mail.gmail.com","threadId":"43267","inReplyTo":"7vy7qdttc0.fsf@assigned-by-dhcp.cox.net","subject":"Re: git fetch --reference?","fromName":"Michael K. Edwards","fromEmail":"medwards.linux@gmail.com","sentAt":"2006-11-15T01:17:04Z","receivedAt":"2006-11-15T01:17:04Z","isPatch":false,"sender":{"key":"medwards.linux@gmail.com","avatar":null},"body":"On 11/14/06, Junio C Hamano wrote:\n> I am somewhat doubtful that this is common enough to warrant\n> adding an extra option to \"git fetch\", but you could add\n> alternates to these new reference object stores before\n> initiating the fetch.\n> ...\n\nThanks, that's what I was looking for. I can just set up a \"tracking\"\ntree where I don't attempt any merges, include it in the alternates\nfor each working tree, and \"git fetch\" in the tracking tree when it's\nconvenient. Now, will tags from the tracking tree propagate into the\nworking trees?\n\nCheers,\n"},{"id":"294365","messageId":"7vu011tr5l.fsf@assigned-by-dhcp.cox.net","threadId":"43267","inReplyTo":"f2b55d220611141717r4507c9demddb1cf872dbee073@mail.gmail.com","subject":"Re: git fetch --reference?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-15T01:49:58Z","receivedAt":"2006-11-15T01:49:58Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Michael K. Edwards\" writes:\n\n> On 11/14/06, Junio C Hamano wrote:\n>> I am somewhat doubtful that this is common enough to warrant\n>> adding an extra option to \"git fetch\", but you could add\n>> alternates to these new reference object stores before\n>> initiating the fetch.\n>> ...\n>\n> Thanks, that's what I was looking for. I can just set up a \"tracking\"\n> tree where I don't attempt any merges, include it in the alternates\n> for each working tree, and \"git fetch\" in the tracking tree when it's\n> convenient. Now, will tags from the tracking tree propagate into the\n> working trees?\n\nFor the working trees, if you \"fetch\" from the tracking tree\nusing short-hand, just like you \"fetch\" from the origin using\nshort-hand, tags will be followed, I think.\n\n"}]}