Yaacov Akiba Slama <ya@slamail.org> writes:

quoted text
> /trunk/path/to/file
> /trunk/new/path/to/file (this is a copy of /branches/branch_1/path/to/file)
> /branches/branch_1/path/to/file
> /branches/branch_n/path/to/file
> /tags/tag_1/path/to/file
> /tags/tag_m/path/to/file
>
> Now the commit 109fc2b97b73090a4a0a6550cdf9b2446fd12389 creates a new 
> commit with two parents:
> 1) HEAD
> 2) the git branch called "branch_1"
>
> From what I read about the definition of commit in git's documentation, 
> that seems to be ok, but can this marking of  "branch_1" as a parent of 
> this commit be dangerous for merges done later in pure git ?

I think it is reasonable to record both as parents, to make the
development history in branch_1 accessible from the trunk branch
after they are merged, and I do not think it is dangerous at
all.  It is just a regular merge which, when viewed from trunk
side of the history, creates a directory called 'new' at the top
level, and adds bunch of files there, and if you are viewing it
with rename/copy detection you may even notice that those
changes are mostly copy edits.

But the above example brings up an interesting question.
Subversion lets you copy freely and does not require the
developer to express machine-readably what that copy is about.
Also it lets copy partial trees.  So it is entirely plausible to
run your project like this:

	1. Repo has /trunk/i386/blah.c; i.e. 'ls' at the
           toplevel of the working tree shows 'i386' directory.

               /trunk/i386/blah.h

        2. Somebody wants to do x86-64 equivalent of existing
           thing, and starts preparing it by copying existing
           i386 thing, into his branch, and do development
           there.

		/trunk/i386/blah.c
                /branches/wip-x86-64/blah.c (copy from /trunk/i386)

        3. Later, that x86-64 equivalent matures, and gets
           merged into trunk:

		/trunk/i386/blah.c
		/trunk/x86-64/blah.c (merge back from /branches/wip-x86-64)
                /branches/wip-x86-64/blah.c (development ceased)

But it is also plausible to do this instead:

	2'. Instead of the above, you copy the whole thing

		/trunk/i386/blah.c
                /branches/wip/i386/blah.c (copy from /trunk)
                /branches/wip/x86-64/blah.c (then copy from /branches/wip/i386)

        3'. Instead of the above:

		/trunk/i386/blah.c (merge back from /branches/wip)
		/trunk/x86-64/blah.c (merge back from /branches/wip)
                /branches/wip/i386/blah.c (development ceased)
                /branches/wip/x86-64/blah.c (development ceased)

Do you need to handle the history resulting from these cases
differently when importing from subversion?  I have a feeling
that the user needs to tell what really happend for you to
handle this sensibly (tree root level is different), but I am
not offhand sure what the issues are.

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html