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
[email protected]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
