Alexander Litvinov wrote: > So, git-svn just a offline-capable version of svn client with linear history. > Sure. you can fork your own branch and then merge it into svn branch again > but you should really careful about this. > > I even does not know the way to solve this problem. The problem is the SVN model. Only now that people have woken up en masse to the fact that tracking merges is actually really important are they adding it to the core. Their system¹ is of course completely incompatible with the predominant tool for this SVK (no complaints there). Thankfully it looks based on the other major solution out there, svnmerge, so hopefully only minor incompatibilities can be expected. My first analysis of the solution is that they have approached this on two levels: commit merge ancestry and file merge ancestry. File merge ancestry, while central to tools like Perforce, is a pretty alien concept to git and almost certainly can be derived (probably more reliably in practice) using git-cherry-type algorithms. I describe this as the "smash patches to pieces" development model on my git-svn tutorial. Commit merge ancestry is however a basic feature in git. They are even going further than that and allowing cherry picks to be tracked as well. This information is currently derived in git using git-cherry. Sam. ¹ http://subversion.tigris.org/merge-tracking/design.html - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
