{"thread":{"id":"28429","subject":"Where is information of \"git read-tree\" stored?","startedAt":"2011-09-19T08:46:31Z","lastAt":"2011-09-25T01:30:45Z","messageCount":5,"participants":["Manuel Reimer","Junio C Hamano","David Aguilar"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"175775","messageId":"loom.20110919T103707-867@post.gmane.org","threadId":"28429","inReplyTo":null,"subject":"Where is information of \"git read-tree\" stored?","fromName":"Manuel Reimer","fromEmail":"manuel.spam@nurfuerspam.de","sentAt":"2011-09-19T08:46:31Z","receivedAt":"2011-09-19T08:46:31Z","isPatch":false,"sender":{"key":"manuel.spam@nurfuerspam.de","avatar":null},"body":"Hello,\n\nfollowing situation:\n\n- Project hosted on GIT. Have a local copy and push to remote server.\n- Small addon is hosted on a remote SVN server\n- I now cloned the SVN to a local GIT (svn git clone)\n- Then I used the instructions from here:\n\n\n\nto get the local SVN copy merged into a subdirectory on my project GIT. Anything\nworked well.\n\nTo test the worst case, I cloned my project GIT to a new local repository. The\nremote connection to the local SVN copy was lost, so I recreated it.\n\nNow, for some reason, I can immediately call\n\ngit pull -s subtree Bproject master\n\nto pull changes from the SVN copy to the subdir... I didn't have to call \"git\nread-tree\" again. Where is this information stored? Why does GIT know where the\nremote repository data has to be placed to? Can I view this information? Can I\nedit it?\n\nIs there some information available somewhere on which data is pushed to server\nand which is only in my local repo?\n\nWhat will happen if my SVN checkout to local GIT repo gets lost? Can I just\nclone this from SVN again, connect this to my project GIT and it will work just\nwell without problems? Or should I keep a copy of this GIT repo on server just\nto be sure nothing bad happens?\n\nThanks in advance\n\nYours\n\nManuel\n"},{"id":"175791","messageId":"7vzki0a0yd.fsf@alter.siamese.dyndns.org","threadId":"28429","inReplyTo":"loom.20110919T103707-867@post.gmane.org","subject":"Re: Where is information of \"git read-tree\" stored?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-09-19T17:36:42Z","receivedAt":"2011-09-19T17:36:42Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Manuel Reimer writes:\n\n> Hello,\n>\n> following situation:\n>\n> - Project hosted on GIT. Have a local copy and push to remote server.\n> - Small addon is hosted on a remote SVN server\n> - I now cloned the SVN to a local GIT (svn git clone)\n> - Then I used the instructions from here:\n>\n> \n>\n> to get the local SVN copy merged into a subdirectory on my project GIT. Anything\n> worked well.\n>\n> To test the worst case, I cloned my project GIT to a new local repository. The\n> remote connection to the local SVN copy was lost, so I recreated it.\n\nIt is unclear to me what you meant by \"connection\" \"lost\" and \"recreated\"\nabove, but I am guessing I can ignore them, as long as I take it that you\nmean by that local mirror from the subversion repository \"Bproject\" below.\n\n> Now, for some reason, I can immediately call\n>\n> git pull -s subtree Bproject master\n>\n> to pull changes from the SVN copy to the subdir... I didn't have to call \"git\n> read-tree\" again.\n\nThat \"how to\" may be badly written and this may have been unclear to you\nbut the first four steps are to be done _only once_ to set things up, and\nafter that you need to run only the fifth step whenever you want to update\nfrom the Bproject. Could you suggest a better wording to update the doc?\n\nThe very first \"subtree merge\" (the one that is recorded with the commit\nafter the read-tree) records all paths from Bproject renamed to elsewhere\nin the merge result (you can view it with \"git show -M\n$that_merge_commit\"), and that is what allows \"pull -s\" (both the initial\none and subsequent ones; indeed the fifth step in the initial round is not\nany more special than the subsequent round) notice where changes from the\nBproject ought to go.\n"},{"id":"175802","messageId":"j586pb$emh$1@dough.gmane.org","threadId":"28429","inReplyTo":"7vzki0a0yd.fsf@alter.siamese.dyndns.org","subject":"Re: Where is information of \"git read-tree\" stored?","fromName":"Manuel Reimer","fromEmail":"manuel.spam@nurfuerspam.de","sentAt":"2011-09-19T19:52:10Z","receivedAt":"2011-09-19T19:52:10Z","isPatch":false,"sender":{"key":"manuel.spam@nurfuerspam.de","avatar":null},"body":"Junio C Hamano wrote:\n> It is unclear to me what you meant by \"connection\" \"lost\" and \"recreated\"\n> above, but I am guessing I can ignore them, as long as I take it that you\n> mean by that local mirror from the subversion repository \"Bproject\" below.\n\nYes. And the reference to it isn't pushed to the remote GIT server. If I clone \nthe remote repo, then \"git remote -v\" doesn't show the reference anymore.\n\n> That \"how to\" may be badly written and this may have been unclear to you\n> but the first four steps are to be done _only once_ to set things up, and\n> after that you need to run only the fifth step whenever you want to update\n> from the Bproject. Could you suggest a better wording to update the doc?\n\nAs long as I don't understand what's going on here, I can't suggest how to \nimprove the documentation.\n\n> The very first \"subtree merge\" (the one that is recorded with the commit\n> after the read-tree) records all paths from Bproject renamed to elsewhere\n> in the merge result (you can view it with \"git show -M\n> $that_merge_commit\")\n\nTried that, but the stuff, I saw on screen, doesn't make clear how GIT knew \nabout what to do here.\n\nI also still don't know how I can restore that whole setup if anything, I have \non my local side, gets lost. Means, that anything, that I have left, is the \nstuff, I pushed to the remote GIT and the SVN, I want to have in my own tree. \nWhich steps do I have to perform to restore the setup and have it working again \nwithout getting conflicts?\n\nMaybe the risk of getting problems is too high and I should copy over stuff, I \ngot from SVN, from time to time manually to my GIT repo?\n\nYours\n\nManuel\n"},{"id":"175818","messageId":"7vobyg89rh.fsf@alter.siamese.dyndns.org","threadId":"28429","inReplyTo":"j586pb$emh$1@dough.gmane.org","subject":"Re: Where is information of \"git read-tree\" stored?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-09-19T22:09:22Z","receivedAt":"2011-09-19T22:09:22Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Manuel Reimer writes:\n\n>> That \"how to\" may be badly written and this may have been unclear to you\n>> but the first four steps are to be done _only once_ to set things up, and\n>> after that you need to run only the fifth step whenever you want to update\n>> from the Bproject. Could you suggest a better wording to update the doc?\n>\n> As long as I don't understand what's going on here, I can't suggest\n> how to improve the documentation.\n>\n>> The very first \"subtree merge\" (the one that is recorded with the commit\n>> after the read-tree) records all paths from Bproject renamed to elsewhere\n>> in the merge result (you can view it with \"git show -M\n>> $that_merge_commit\")\n>\n> Tried that, but the stuff, I saw on screen, doesn't make clear how GIT\n> knew about what to do here.\n\nTo a certain degree, the point of a tool is that the user does not need to\nknow about the details, but if you are interested...\n\nSuppose you have this tree structure in your \"original\" project:\n\n Documentation/README.txt\n hello.c\n\tMakefile\n\nand then somebody else has this structure in his project (in your case, it\nmay happen to be stored in SVN but once it is slurped in a git repository,\nit does not matter):\n\n goodbye.c\n\tMakefile\n\nFurther suppose that you would want to end up with this tree structure:\n\n Documentation/README.txt\n\tMakefile\n hello.c\n imported/Makefile\n imported/goodbye.c\n\ni.e. you would want to move stuff that came from the other project in imported/\nhierarchy. There may be many other files, and even subdirectories, in the\nother project, but they all are shifted one level down and placed in imported/\nhierarchy.\n\nThe first four steps of the howto is to create such a final tree structure\nand make a merge commit out of that tree.\n\nAfter you update your project (which now has both the original files such\nas hello.c etc., may have added new files, and may even have updated stuff\ninside imported/ hierarchy) and the other side updated their project (e.g.\nit may have updated goodbye.c whose change you would want to carry over to\nyour imported/goodbye.c, or it may have added a new file welcome.c, which\nyou would want to import as imported/welcome.c), you would invoke \"pull -s\nsubtree\", which in turn runs \"merge -s subtree\".\n\nThe subtree strategy first compares the shapes of two trees being merged,\nand tries to find how much they have to be shifted to match. Your tree\nmay now have:\n\n Documentation/README.txt\n\tMakefile\n\thello.h (added)\n hello.c\n imported/Makefile\n imported/goodbye.c\n\nwhile the other side may now have:\n\n goodbye.c\n\tMakefile\n\twelcome.c\n\nThe subtree strategy notices that by prefixing \"imported/\" in front of the\npaths, the tree from the other side will match the shape of the subtree\nyou have under \"imported/\". Thus it can pair:\n\n\ttheir \"goodbye.c\" with your \"imported/goodbye.c\"\n their \"Makefile\" with your \"imported/Makefile\"\n their \"welcome.c\" with your \"imported/welcome.c\"\n\nand merge the changes. The common ancestor commit of this merge will be\nthe initial merge you made with the first 4-step, so the three-way merge\nlogic would notice that there wasn't \"welcome.c\" in the beginning, they\nadded that path, while you did not do anything to the path that\ncorresponds to it (namely, \"imported/welcome.c\"), so the new \"welcome.c\"\nfile from the other project would simply be copied as \"imported/welcome.c\"\nto your tree, and the change they made to \"goodbye.c\" and your changes you\nmade to your \"imported/goodbye.c\" will be merged and result is recorded in\nyour \"imported/goodbye.c\".\n\nIf \"compares the shape and figures out how much to shift\" makes you feel\nuneasy (and it probably should), you can give an explicit directory prefix \nas the backend option \"subtree\" (see \"git merge help\" for details).\n"},{"id":"176149","messageId":"20110925013043.GB19780@gmail.com","threadId":"28429","inReplyTo":"7vobyg89rh.fsf@alter.siamese.dyndns.org","subject":"Re: Where is information of \"git read-tree\" stored?","fromName":"David Aguilar","fromEmail":"davvid@gmail.com","sentAt":"2011-09-25T01:30:45Z","receivedAt":"2011-09-25T01:30:45Z","isPatch":false,"sender":{"key":"davvid@gmail.com","avatar":"https://avatars.githubusercontent.com/u/13196?v=4"},"body":"On Mon, Sep 19, 2011 at 03:09:22PM -0700, Junio C Hamano wrote:\n> \n> To a certain degree, the point of a tool is that the user does not need to\n> know about the details, but if you are interested...\n\ngit-subtree allows you to not have to know about the details:\n\nhttps://github.com/apenwarr/git-subtree\n\nhttps://github.com/apenwarr/git-subtree/blob/master/git-subtree.txt\n\ngit-subtree, combined with Junio's wonderful write-up below,\nshould get you on the right track.\n\n\n> Suppose you have this tree structure in your \"original\" project:\n> \n> Documentation/README.txt\n> hello.c\n> \tMakefile\n> \n> and then somebody else has this structure in his project (in your case, it\n> may happen to be stored in SVN but once it is slurped in a git repository,\n> it does not matter):\n> \n> goodbye.c\n> \tMakefile\n> \n> Further suppose that you would want to end up with this tree structure:\n> \n> Documentation/README.txt\n> \tMakefile\n> hello.c\n> imported/Makefile\n> imported/goodbye.c\n> \n> i.e. you would want to move stuff that came from the other project in imported/\n> hierarchy. There may be many other files, and even subdirectories, in the\n> other project, but they all are shifted one level down and placed in imported/\n> hierarchy.\n> \n> The first four steps of the howto is to create such a final tree structure\n> and make a merge commit out of that tree.\n> \n> After you update your project (which now has both the original files such\n> as hello.c etc., may have added new files, and may even have updated stuff\n> inside imported/ hierarchy) and the other side updated their project (e.g.\n> it may have updated goodbye.c whose change you would want to carry over to\n> your imported/goodbye.c, or it may have added a new file welcome.c, which\n> you would want to import as imported/welcome.c), you would invoke \"pull -s\n> subtree\", which in turn runs \"merge -s subtree\".\n> \n> The subtree strategy first compares the shapes of two trees being merged,\n> and tries to find how much they have to be shifted to match. Your tree\n> may now have:\n> \n> Documentation/README.txt\n> \tMakefile\n> \thello.h (added)\n> hello.c\n> imported/Makefile\n> imported/goodbye.c\n> \n> while the other side may now have:\n> \n> goodbye.c\n> \tMakefile\n> \twelcome.c\n> \n> The subtree strategy notices that by prefixing \"imported/\" in front of the\n> paths, the tree from the other side will match the shape of the subtree\n> you have under \"imported/\". Thus it can pair:\n> \n> \ttheir \"goodbye.c\" with your \"imported/goodbye.c\"\n> their \"Makefile\" with your \"imported/Makefile\"\n> their \"welcome.c\" with your \"imported/welcome.c\"\n> \n> and merge the changes. The common ancestor commit of this merge will be\n> the initial merge you made with the first 4-step, so the three-way merge\n> logic would notice that there wasn't \"welcome.c\" in the beginning, they\n> added that path, while you did not do anything to the path that\n> corresponds to it (namely, \"imported/welcome.c\"), so the new \"welcome.c\"\n> file from the other project would simply be copied as \"imported/welcome.c\"\n> to your tree, and the change they made to \"goodbye.c\" and your changes you\n> made to your \"imported/goodbye.c\" will be merged and result is recorded in\n> your \"imported/goodbye.c\".\n> \n> If \"compares the shape and figures out how much to shift\" makes you feel\n> uneasy (and it probably should), you can give an explicit directory prefix \n> as the backend option \"subtree\" (see \"git merge help\" for details).\n\n-- \n\t\t\t\t\tDavid\n"}]}