Junio C Hamano wrote: >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.htmlReceived on Thu Nov 10 20:55:16 2005
This archive was generated by hypermail 2.1.8 : 2005-11-10 20:55:21 EST