{"thread":{"id":"5779","subject":"Multiple checkouts of the same repository","startedAt":"2006-10-01T19:03:24Z","lastAt":"2006-10-03T07:59:57Z","messageCount":8,"participants":["Matt McCutchen","Johannes Schindelin","Daniel Barkalow","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"28074","messageId":"3bbc18d20610011203p40d631b7o3bd2c6971a2bfcca@mail.gmail.com","threadId":"5779","inReplyTo":null,"subject":"Multiple checkouts of the same repository","fromName":"Matt McCutchen","fromEmail":"hashproduct+git@gmail.com","sentAt":"2006-10-01T19:03:24Z","receivedAt":"2006-10-01T19:03:24Z","isPatch":false,"sender":{"key":"hashproduct+git@gmail.com","avatar":null},"body":"Dear git people,\n\nMaybe this is common knowledge, but I thought I should mention it in\ncase it isn't. I had a git repository in a directory A and I wanted\nto check out a branch of the repository to a different directory B.\nSo I created B/.git and filled it with symlinks pointing to the files\nin A/.git, except for index and HEAD because those need to be\ndifferent for each checkout; then I ran git-checkout to fill\nB. Now I can view and edit each checkout independently, but they are\nbacked by the same set of objects and refs. However, I must remember\nto commit to each branch only through the checkout whose HEAD is\nlinked to it, otherwise that checkout won't get updated.\n\nMatt\n"},{"id":"28075","messageId":"Pine.LNX.4.63.0610012105590.14200@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"5779","inReplyTo":"3bbc18d20610011203p40d631b7o3bd2c6971a2bfcca@mail.gmail.com","subject":"Re: Multiple checkouts of the same repository","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-10-01T19:08:34Z","receivedAt":"2006-10-01T19:08:34Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 1 Oct 2006, Matt McCutchen wrote:\n\n> Maybe this is common knowledge, but I thought I should mention it in\n> case it isn't. I had a git repository in a directory A and I wanted\n> to check out a branch of the repository to a different directory B.\n> So I created B/.git and filled it with symlinks pointing to the files\n> in A/.git, except for index and HEAD because those need to be\n> different for each checkout;\n\nA better method is to use a local clone:\n\n\tgit-clone --local --shared A B\n\nSuch a clone will be very fast, and cheap, because it sets up links (not \njust symbolic links, but links that git understands).\n\nHth,\nDscho\n"},{"id":"28076","messageId":"3bbc18d20610011214y6132d98eq9cd58b23721bb87d@mail.gmail.com","threadId":"5779","inReplyTo":"Pine.LNX.4.63.0610012105590.14200@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: Multiple checkouts of the same repository","fromName":"Matt McCutchen","fromEmail":"hashproduct+git@gmail.com","sentAt":"2006-10-01T19:14:46Z","receivedAt":"2006-10-01T19:14:46Z","isPatch":false,"sender":{"key":"hashproduct+git@gmail.com","avatar":null},"body":"On 10/1/06, Johannes Schindelin wrote:\n> A better method is to use a local clone:\n>\n> git-clone --local --shared A B\n>\n> Such a clone will be very fast, and cheap, because it sets up links (not\n> just symbolic links, but links that git understands).\n\nBut that gives me two separate repositories, so I have to push and\npull to keep them in sync, which is a pain.\n\nI symlinked only the top-level things in .git, not the individual\nfiles inside them. That is to say, B/.git/objects is a symlink to\nA/.git/objects, B/.git/refs is a symlink to A/.git/refs, etc. In\nfact, this is necessary for A to see objects and refs written through\nB.\n\nMatt\n"},{"id":"28077","messageId":"Pine.LNX.4.63.0610012116310.14200@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"5779","inReplyTo":"3bbc18d20610011214y6132d98eq9cd58b23721bb87d@mail.gmail.com","subject":"Re: Multiple checkouts of the same repository","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-10-01T19:17:57Z","receivedAt":"2006-10-01T19:17:57Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 1 Oct 2006, Matt McCutchen wrote:\n\n> On 10/1/06, Johannes Schindelin wrote:\n> > A better method is to use a local clone:\n> > \n> > git-clone --local --shared A B\n> > \n> > Such a clone will be very fast, and cheap, because it sets up links (not\n> > just symbolic links, but links that git understands).\n> \n> But that gives me two separate repositories, so I have to push and\n> pull to keep them in sync, which is a pain.\n\nSo you want the commits to show in A, too? I propose using a hook for \nthat.\n\nThe fact is, your setup is fragile, and I think that is hard to fix if you \ndo not make A and B git repositories in their own right.\n\nHth,\nDscho\n"},{"id":"28088","messageId":"3bbc18d20610011404x52d8ba15ib51ac2a7060bd25e@mail.gmail.com","threadId":"5779","inReplyTo":"Pine.LNX.4.63.0610012116310.14200@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: Multiple checkouts of the same repository","fromName":"Matt McCutchen","fromEmail":"hashproduct+git@gmail.com","sentAt":"2006-10-01T21:04:36Z","receivedAt":"2006-10-01T21:04:36Z","isPatch":false,"sender":{"key":"hashproduct+git@gmail.com","avatar":null},"body":"On 10/1/06, Johannes Schindelin wrote:\n> The fact is, your setup is fragile, and I think that is hard to fix if you\n> do not make A and B git repositories in their own right.\n\nI think my setup is much simpler than having two separate repositories\nthat update each other using hooks. What can go wrong, besides the\nscenario I mentioned where one working tree doesn't get updated when I\ncommit through the other one?\n\nMatt\n"},{"id":"28107","messageId":"Pine.LNX.4.63.0610021214070.14200@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"5779","inReplyTo":"3bbc18d20610011404x52d8ba15ib51ac2a7060bd25e@mail.gmail.com","subject":"Re: Multiple checkouts of the same repository","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-10-02T10:16:15Z","receivedAt":"2006-10-02T10:16:15Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 1 Oct 2006, Matt McCutchen wrote:\n\n> On 10/1/06, Johannes Schindelin wrote:\n> > The fact is, your setup is fragile, and I think that is hard to fix if you\n> > do not make A and B git repositories in their own right.\n> \n> I think my setup is much simpler than having two separate repositories\n> that update each other using hooks. What can go wrong, besides the\n> scenario I mentioned where one working tree doesn't get updated when I\n> commit through the other one?\n\nI do not know, but it feels wrong. Git does not expect something like \nthis, much like an operating system does not expect another computer to \naccess its root hard disk. So _I_ think your setup is fragile.\n\nCiao,\nDscho\n"},{"id":"28126","messageId":"Pine.LNX.4.64.0610022234330.9789@iabervon.org","threadId":"5779","inReplyTo":"3bbc18d20610011404x52d8ba15ib51ac2a7060bd25e@mail.gmail.com","subject":"Re: Multiple checkouts of the same repository","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2006-10-03T02:52:31Z","receivedAt":"2006-10-03T02:52:31Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Sun, 1 Oct 2006, Matt McCutchen wrote:\n\n> On 10/1/06, Johannes Schindelin wrote:\n> > The fact is, your setup is fragile, and I think that is hard to fix if you\n> > do not make A and B git repositories in their own right.\n> \n> I think my setup is much simpler than having two separate repositories\n> that update each other using hooks. What can go wrong, besides the\n> scenario I mentioned where one working tree doesn't get updated when I\n> commit through the other one?\n\nIt works fine, so long as you never modify in A the head that's checked \nout in B; if you do this, git will be very confused, because it doesn't \nrecord in the index what commit the index comes from. I did this for a \nwhile, but eventually switched to just having a single branch checked out \nat a time. (The other thing is that you probably want to have the \nnon-symlinked repository be bare, i.e., not checked out, and have multiple \nsets of symlinks to its parts, so if you decide to discard a working \ndirectory, you don't accidentally delete the one with the repository \nactually in it.)\n\nAt one point, I was arguing for storing the information of what commits \nwere the starting point of the current index in the index itself, instead \nof relying on external files and external links to refs, but I wasn't \nreally working on git enough to argue for it effectively. Among other \nthings, it would allow git to know what's going on if the head changes \nwithout the index getting updated. (Of course, all of the cases it \nsupports are really ones where git should just tell you that you've done \nsomething wrong, because you can't really do non-linear work in a single \nhead sensibly, because there's only one ref for the head, which can't jump \nsideways from the commit that's been pulled or generated elsewhere to the \ncommit that's being generated from the index; if the head doesn't match \nthe commit the index is from, there is no alternative to a \nmerge-before-commit, which is frowned upon in the git world as a way of \nlosing your recent work. This is why I couldn't convince people very \nwell.)\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"28134","messageId":"7vzmcdrfr6.fsf@assigned-by-dhcp.cox.net","threadId":"5779","inReplyTo":"Pine.LNX.4.64.0610022234330.9789@iabervon.org","subject":"Re: Multiple checkouts of the same repository","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-10-03T07:59:57Z","receivedAt":"2006-10-03T07:59:57Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Daniel Barkalow writes:\n\n> At one point, I was arguing for storing the information of what commits \n> were the starting point of the current index in the index itself, instead \n> of relying on external files and external links to refs, but I wasn't \n> really working on git enough to argue for it effectively. Among other \n> things, it would allow git to know what's going on if the head changes \n> without the index getting updated. (Of course, all of the cases it \n> supports are really ones where git should just tell you that you've done \n> something wrong,...\n\nI think if you really wanted to, you could put it in the index\nextension section along with the cache-tree data. We would need\nto implement a way to query and manipulate data in the index\nextension and update git-commit (it should check HEAD matches\nthe commit you placed in the extension earlier, and after making\na commit and updating HEAD, you should update the index with the\nnew commit as well), git-checkout (after switching branches you\nshould update the index with the branch head you switched to; I\nthink you should sanity check before switching to see if the\ncurrent index and HEAD are reasonable as well but I am not\nsure), git-reset --hard (set to the resetted HEAD), git-am,\ngit-applymbox, and git-merge (check before and set after when\nsuccessful).\n"}]}