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

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

[Manuel Reimer]

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

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

[Junio C Hamano]

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

> 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.

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.

> 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.

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.

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

[Manuel Reimer]

Junio C Hamano wrote:
> 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.

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.

> 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?

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

> 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")

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

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

[Junio C Hamano]

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

>> 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?
>
> As long as I don't understand what's going on here, I can't suggest
> how to improve the documentation.
>
>> 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")
>
> Tried that, but the stuff, I saw on screen, doesn't make clear how GIT
> knew about what to do here.

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).

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

[David Aguilar]

On Mon, Sep 19, 2011 at 03:09:22PM -0700, Junio C Hamano wrote:
> 
> 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...

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.


> 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).

-- 
					David