Ludovic Rousseau wrote: > >> on the SM branch use: "git format-patch origin" to get the changes > >> in individual patch files. > >> on the gerrit/staging use: "git am my_patch" for all the previously > >> generated patches. > > > > I would avoid doing this manually. git rebase really is the way to go. > > I am still lost when git rebase fails. I need to improve my git skills.
You mean if there is a conflict somewhere along the way? Then the rebase only pauses, and expects the conflict to be fixed manually, then: git add fixed files && git rebase --continue ..which will continue with the following commits or instructions from the interactive rebase script. > >> Do not apply all the patches at once but one after the other (in > >> the correct order) and rebuild after each patch. The source code > >> shall compile after each change or gerrit will reject it. > > > > This can actually be automated pretty easily after the fact. I would > > first do the complete rebase and only after test each commit on the > > branch. > > How do you do that? for c in $(git rev-list gerrit/staging..HEAD); do git checkout master git branch -D test_$c git checkout -b test_$c $c # run test here test $? -eq 0 && { git branch -D test_$c continue } # tests failed echo TEST FAILED git log -1 | cat done > >> I had the problem yesterday: a compilation bug that was fixed by > >> another patch. I had to merge the two patches. > > > > Another solution may be to reorder the commits. Interactive rebase > > makes this very easy once the commits have been found. > > Reorder and merge the problematic change with the fix. I know who to > do that :-) I meant that the changes can also be reordered without needing to merge them. Sometimes that's preferable. //Peter _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel