Junio C Hamano wrote:

quoted text
>Although I did not hear anybody jumping up-and-down to merge
>svnimport updates from Yaacov Akiba Slama, I did not hear it
>broke things either, so it graduated to the master branch and
>included in this release.  It obviously improved things for
>Yaacov, and I am hoping this would not cause disruptions for
>people's existing setup.
>  
>
Thanks for the merge.
IMHO, the commit labelled 
"Bundle file copies from multiple branches into a merge" 
(109fc2b97b73090a4a0a6550cdf9b2446fd12389) needs more attention/discussion.

In svn, there is no concept of branches or tag, but because the copy is 
cheap, directories are used to simulate branches and tags.
The repository will be like :

/trunk/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, someone can copy directory or files from the trunk or any 
branch/tag into any other directory. For instance one can commit the 
following tree as a new revision :

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

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