Luis Gutierrez venit, vidit, dixit 22.08.2008 15:13: > Hi All, > > During the past year or so we have been using a bastardized version of > CVS in which branches were not 'true' cvs branches, but just a copy of > the original data in a different folder. For instance, we would have > something like this: > > ProjectX > \---- dev01 > | \... normal cvs data > \---- dev02 > | \... normal cvs data > \---- release01 > | \... normal cvs data > \---- release02 > \... normal cvs data > > While a timeline of the branches looks like this: > > /---release01 > ----dev01------+ /---release02 > \---dev02------+-- > > Now that we are trying to move to git, and I'm having problems importing > the projects with their full history. > > What I have done is use git-cvsimport on each of those branches to > create separate git repositories: dev01, dev02, release01, and release02. > > What I was planing on doing next was: > (all from the dev01 branch) > 1) git branch dev01 > 2) git checkout -b release01 > 3) git pull ssh:/..../release01 > 4) git checkout -b dev02 > 5) git pull ssh:/..../dev02 > 6) git checkout -b release02 > 7) git pull ssh:/..../release02 > > Now, the problem I'm seeing is that I get hundreds of conflicts when > pulling. > > Short from doing a git-mergetool 100's of times, is there a better way > of doing this? One that guarantees I keep the latests version (ie, the > one I'm pulling from). > Put in another way, is there a way to let git know that it will not > merge the last version of the files, just the history? > > Cheers. > > Luis Gutierrez How about: - fetch instead of pull - After each fetch, put the fetched thing in a local branch: git checkout -b release01 FETCH_HEAD Now you've got local "branches" without a common root. Finally, stitch it together using grafts and filter-branch. Michael -- 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
