Paul Mossman wrote: > Damian wrote: >> I am running my >> builds/tests from a separate view, checking the source out >> before compiling and testing it. I take so many patches that >> this is really the only way to go. >> >> Just 'git clone' your local git repo - it takes 15 seconds. >> >> My 'test-branch' script looks something like this: > > Omitting new files from the changeset has burned me a couple times now. > I will look into using a cloned git repo for testing, and hopefully stop > getting burned. > > Though in this case it was a subversion repo. Is there some (easy) git > magic I could have used instead of svnmerge.py? >
Absolutely. It's actually much easier to merge and rebase in git than it is in subversion. All sipXconfig merges from 3.10 to main and from 4.0 to main were done in git. And that's how I rebased new_skin branch for martin's demo (user_martins_demo branch) Start with the repo that mirrors all subversion branches. Create a new git branch based on the topic branch you want to merge. # make sure you are up to date and that merge point to subversion trunk tip git svn fetch git co master git reset --hard svn/trunk # create a new branch - this is where you'll be merging/rebasing git co -b my_new_skin svn/mdasilva_new_skin # rebase your branch on top of master (svn/trunk) git rebase master # you'll have conflicts at this point - to resolve them run git mergetool git rebase --continue # until nothing more to rebase You'll end up with entire branch on top of the latest master. It makes sense to have 'meld' or some other graphical merge tool installed. The reason it's easier than svnmerge is that you get to merge each revision separately, the merge direction is more natural and usually you're merging smaller change sets. You don't have to do everything at once. You can repeat the process without always starting from the very beginning. You can also test the results without committing this to subversion. Generate patches for other to tests etc. And if something goes wrong: you can restart it without affecting anybody else. Once you happy with the new branch you can dcommit it to master or to other subversion branch created of off current master tip. Just as you'd have committed your own changes or a patch. D. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
