On 5 April 2012 00:16, [email protected]
<[email protected]> wrote:
>> Yeah, this is where the merging instead of rebasing thing strategy
>> comes in handy. You just do all your changes in branches, and merge
>> them together when you need them. Since the merge doesn't affect the
>> original commit, this won't create duplicate commits, and will extend
>> naturally when the commit is merged into master.
>>
>
> When you have the time could you explain (or point to an explanation)
> about the merge vs rebase strategy. It is not clear to me how this
> works.
Do you mean that if I have:
sympy_master_A -------- A ------------ B ------------- C ----M--------
D my_branch
| |
|-----------E---------------F---------------| my_merged_branch
I can make a pull request for both "my_merged_branch" and "my_branch"
and don't worry about which pull request gets merged first? But the
commit M that represent the merge creates a problem, no?
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sympy?hl=en.
