Where is information of "git read-tree" stored?

Hello,

following situation:

- Project hosted on GIT. Have a local copy and push to remote server.
- Small addon is hosted on a remote SVN server
- I now cloned the SVN to a local GIT (svn git clone)
- Then I used the instructions from here:

<http://git-mirror.googlecode.com/git-history/7444c60/howto/using-merge-subtree.html>

to get the local SVN copy merged into a subdirectory on my project GIT. Anything worked well.

To test the worst case, I cloned my project GIT to a new local repository. The remote connection to the local SVN copy was lost, so I recreated it.

Now, for some reason, I can immediately call

git pull -s subtree Bproject master

to pull changes from the SVN copy to the subdir... I didn't have to call "git read-tree" again. Where is this information stored? Why does GIT know where the remote repository data has to be placed to? Can I view this information? Can I edit it?

Is there some information available somewhere on which data is pushed to server and which is only in my local repo?

What will happen if my SVN checkout to local GIT repo gets lost? Can I just clone this from SVN again, connect this to my project GIT and it will work just well without problems? Or should I keep a copy of this GIT repo on server just to be sure nothing bad happens?

Thanks in advance

Yours

Manuel

Manuel Reimer <manuel.spam@nurfuerspam.de> writes:

It is unclear to me what you meant by "connection" "lost" and "recreated" above, but I am guessing I can ignore them, as long as I take it that you mean by that local mirror from the subversion repository "Bproject" below.

That "how to" may be badly written and this may have been unclear to you but the first four steps are to be done _only once_ to set things up, and after that you need to run only the fifth step whenever you want to update from the Bproject. Could you suggest a better wording to update the doc?

The very first "subtree merge" (the one that is recorded with the commit after the read-tree) records all paths from Bproject renamed to elsewhere in the merge result (you can view it with "git show -M $that_merge_commit"), and that is what allows "pull -s" (both the initial one and subsequent ones; indeed the fifth step in the initial round is not any more special than the subsequent round) notice where changes from the Bproject ought to go.

Junio C Hamano wrote:

Yes. And the reference to it isn't pushed to the remote GIT server. If I clone the remote repo, then "git remote -v" doesn't show the reference anymore.

As long as I don't understand what's going on here, I can't suggest how to improve the documentation.

Tried that, but the stuff, I saw on screen, doesn't make clear how GIT knew about what to do here.

I also still don't know how I can restore that whole setup if anything, I have on my local side, gets lost. Means, that anything, that I have left, is the stuff, I pushed to the remote GIT and the SVN, I want to have in my own tree. Which steps do I have to perform to restore the setup and have it working again without getting conflicts?

Maybe the risk of getting problems is too high and I should copy over stuff, I got from SVN, from time to time manually to my GIT repo?

Yours

Manuel

Manuel Reimer <Manuel.Spam@nurfuerspam.de> writes:

To a certain degree, the point of a tool is that the user does not need to know about the details, but if you are interested...

Suppose you have this tree structure in your "original" project:

        Documentation/README.txt
        hello.c
	Makefile

and then somebody else has this structure in his project (in your case, it may happen to be stored in SVN but once it is slurped in a git repository, it does not matter):

        goodbye.c
	Makefile

Further suppose that you would want to end up with this tree structure:

        Documentation/README.txt
	Makefile
        hello.c
        imported/Makefile
        imported/goodbye.c

i.e. you would want to move stuff that came from the other project in imported/ hierarchy. There may be many other files, and even subdirectories, in the other project, but they all are shifted one level down and placed in imported/ hierarchy.

The first four steps of the howto is to create such a final tree structure and make a merge commit out of that tree.

After you update your project (which now has both the original files such as hello.c etc., may have added new files, and may even have updated stuff inside imported/ hierarchy) and the other side updated their project (e.g. it may have updated goodbye.c whose change you would want to carry over to your imported/goodbye.c, or it may have added a new file welcome.c, which you would want to import as imported/welcome.c), you would invoke "pull -s subtree", which in turn runs "merge -s subtree".

The subtree strategy first compares the shapes of two trees being merged, and tries to find how much they have to be shifted to match. Your tree may now have:

        Documentation/README.txt
	Makefile
	hello.h (added)
        hello.c
        imported/Makefile
        imported/goodbye.c

while the other side may now have:

        goodbye.c
	Makefile
	welcome.c

The subtree strategy notices that by prefixing "imported/" in front of the paths, the tree from the other side will match the shape of the subtree you have under "imported/". Thus it can pair:

	their "goodbye.c" with your "imported/goodbye.c"
        their "Makefile" with your "imported/Makefile"
        their "welcome.c" with your "imported/welcome.c"

and merge the changes. The common ancestor commit of this merge will be the initial merge you made with the first 4-step, so the three-way merge logic would notice that there wasn't "welcome.c" in the beginning, they added that path, while you did not do anything to the path that corresponds to it (namely, "imported/welcome.c"), so the new "welcome.c" file from the other project would simply be copied as "imported/welcome.c" to your tree, and the change they made to "goodbye.c" and your changes you made to your "imported/goodbye.c" will be merged and result is recorded in your "imported/goodbye.c".

If "compares the shape and figures out how much to shift" makes you feel uneasy (and it probably should), you can give an explicit directory prefix as the backend option "subtree" (see "git merge help" for details).

On Mon, Sep 19, 2011 at 03:09:22PM -0700, Junio C Hamano wrote:

git-subtree allows you to not have to know about the details:

https://github.com/apenwarr/git-subtree

https://github.com/apenwarr/git-subtree/blob/master/git-subtree.txt

git-subtree, combined with Junio's wonderful write-up below, should get you on the right track.