the ascii art got wrapped:
sympy_master ---- A ---- B ----M-----C my_branch
| |
|---E----- | my_merged_branch
On 5 April 2012 00:23, [email protected]
<[email protected]> wrote:
> 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.
