Cherrypick commit orders

Question

That might be a naive git question but here it is:

Before doing a pull-request, I usually create a new branch from the latest commits in the upstream and cherry-pick the important commits from my development branch. Then make a pull-request from my new branch to the remote repository.

But I hate the merge-conflicts (although the git mergetool helps a lot when they occur). I suspect that some of those conflicts caused by the order of cherrypicks. I usually cherrypick a set of commits from oldest to newest commit. Is this the correct approach. Or commit order doesn't matter for git?

Is there any other tricks for minimizing the merge conflicts during cherry-picking?

Answer 1

You should definitely cherry-pick commits in order. If you don't, they may not apply - imagine that one commit adds foo.c, and the next one modifies it. Clearly they're not going to work out of order. In general, even if it's not that obvious, there's some logical flow of development, and you don't want to mess with it. That said, I'm not sure why you're manually creating a branch and cherry-picking; it's equivalent (as long as you're not skipping commits) to git pull --rebase.

If you're getting merge conflicts when cherry-picking, it's more a sign that your development process isn't ideal. It means that the things you're working on in your development branch are also being changed upstream. You might be able to help yourself out by either not working on the same code others are working on, or by more frequently pulling (probably pull --rebase, again) from upstream during development, rather than waiting until the very end.