Alex Riesen wrote: >> So it looks like you wouldn't _need_ to split source tree into separate >> smaller repositories for performance reasons. Still it might be good >> idea to put separate (sub)projects into separate repositories. But >> I guess you can do that even at later time (although it would be best >> to do this upfront). >> > > It looks like they use P4 branches. Which are NOT branches as Git > understands it (a line of history). The P4 "branches" are just directories > with some metadata regarding recording where the data in the directory > were before an act of "branching" (just a server-side recursive copy). > > In this case (and this must be, as there are no other branches in P4), > they'll have to split their repository. p4's branches are 'close enough'. My tool travels through the history of the repository forwards, detects paths where new content was placed and calls those roots. When branching is detected (recorded file-by-file in perforce), it puts the branch source as a new parent. When branches are 'integrated', it makes a fuzzy decision based on the number of outstanding merges it thinks are due, also based on a merge base calculation on the current view of the derived history. It allows manual correction of this fuzzy information, and arbitrary grafting along the way. Discrepancies between the fuzzy decision and the actual integration records are recorded in the commit log along with other metadata including the commit ID. Sam -- 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