git question

git_question

sympy_master --------A---------B----------C-----Merge_commit--------D   <--my_pull_request_branch_1
                         \                       /
                          \-----E---------F-----/
                                          ^--my_pull_request_branch_2

Is it ok to have those two branches as pull requests? Does it matter which one goes in first?

As far as I understand git, this will happen:

Merge first F, then D:
F will be a fast-forward.
D will be a fast-forward, too, skipping B and C since these are already in Merge_commit.

Merge first D, then F:
D will be a fast-forward.
F will give an error message. Which is a Good Thing because you don't really want to undo Merge_commit. If the merge is with -f, you'll end with the state of F anyway.

Whether the second scenario is a problem or not depends on the people doing the pulls.
Specifically, whether they will know what to do in scenario 2.

BTW things get more interesting if you do fixes on F after D was pulled.
In that situation, a merge between master and your new HEAD will be required.

As I said, I'm not a 100% git expert yet, so take this with a grain of salt; this is just what I'd expect will happen.

F will give an error message. Which is a Good Thing because you don't really want to undo Merge_commit. If the merge is with -f, you'll end with the state of F anyway.

Strictly speaking, it won't give an error message. It will just tell you that it is already up-to-date, meaning that you are trying to merge a commit into a branch that is already there.

In that situation, a merge between master and your new HEAD will be required.

This is right. But it's not an issue. You can think of merge commits as just drawing lines from one branch to another in the history graph. Rebasing moves commits around and deletes lines, but merging only draws new ones.