I have forked an SVN project using Git because I needed to add features that they didn't want. But at the same time, I wanted to be able to continue pulling in features or fixes that they added to the upstream version down into my fork (where they don't conflict). So, I have my Git project with the following branches:
So, my flow is something like this:
git checkout vendor-svn
git svn rebase
git checkout vendor
git merge vendor-svn
git push origin vendor
Now, the question comes here: I need to review each commit that they made (preferably individually since at this point I'm about twenty commits behind them) before merging them into master. I know that I could run git checkout master; git merge vendor, but this would pull in all changes and commit them, without me being able to see if they conflict with what I need.
So, what's the best way to do this? Git seems like a great tool for handling forks of projects since you can pull and push from multiple repos - I'm just not experienced with it enough to know the best way of doing this.
Here's the original SVN project I'm talking about: https://appkonference.svn.sourceforge.net/svnroot/appkonference
My fork is at github.com/jthomerson/AsteriskAudioKonf
It seems like you should just create a branch off of master for your testing:
git checkout -b testing master
git merge vendor-svn
# test...
git checkout master
git merge testing
Or, if you want to test individual commits, you could merge them all individually at once:
git checkout -b testing master
git log --pretty=%H testing..version-svn | while read commit; do git merge $commit || break; done
# now go check out and test each merge that was created
Or one at a time:
git checkout -b testing master
git merge $(git log --pretty=%H testing..version-svn | tail -n 1)
# now test the result, and if you're okay...
# run the merge command again to merge the next commit
git merge $(git log --pretty=%H testing..version-svn | tail -n 1)
# and so on
You'll probably like the latter better, since you can test that commit before bothering to merge the next one. The history will be ugly, so you'd obviously want to go back and redo it all as one merge later.
Either way be sure and set rerere.enabled
to true so that git will remember how you've resolved conflicts, and when you go back and redo the merge straight into master, you won't have to resolve them over again!
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With