On Tue, Jul 14, 2015 at 10:32 AM, Joachim Durchholz <j...@durchholz.org>
wrote:
> Am 14.07.2015 um 16:39 schrieb Jason Moore:
>
>> It wasn't ignored, I just don't see it. All I see are detailed agreements
>> or counters to each point that has been mentioned to be negative about
>> rebasing.
>>
>
> Indeed, I misrepresented that a bit.
> I can't hope to discuss solution details if we don't even agree on the
> analysis. Even less if the solution isn't 100% complete yet.
>
> Here is my two sentence solution:
>>
>> Rebasing has enough substantial negative effects on contributions that
>> we'd
>> like to avoid encouraging it and using it in SymPy development. The few
>> benefits that rebasing offers are not worth the cost of the loss
>> contributions.
>>
>> Can you write a two sentence solution to solving the loss of contributions
>> due to git kung fu issues? I'm happy to read it if so.
>>
>
> 1) I think the negative effects can be nullified by giving people a
> tried-and-true, undoable git workflow ("I think" is what I meant with
> "incomplete" above).
>
If all you care about is the ability to undo things, git revert works just
fine. It has far fewer pitfalls than rebasing, and maintains the record
that the thing was reverted.
2) Rebasing is the only way to clean up a PR that has undergone several
> rounds of review.
>
This clean up is very often unnecessary, and indeed, detrimental to anyone
who wants to study the git history to see how things developed (and if you
don't care about that, then the history doesn't matter anyway).
You shouldn't think of the git history as something that you should clean
up and make nice before publishing. It's a record of your thought process.
You can't go back and change your thought process. The final published item
is the code itself (we don't include any metadata from git in the files we
release on PyPI).
Changing the history of your revisions is detrimental to the open
philosophy that you should have when developing in open source. We should
not be afraid to make mistakes, and even have it in a permanent record that
we made those mistakes. Good open source software, certainly SymPy, is
built in the bazaar, not the cathedral.
Aaron Meurer
> My two-sentence position on the current official policy:
>
> A) Rebasing is indeed a more advanced use of git, so it should never be
> requested, and recommended only with a reference to the explanation of the
> workflow.
> B) The current official policy is too strict, the justifications are
> either bogus or can be avoided.
>
> --
> You received this message because you are subscribed to the Google Groups
> "sympy" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sympy+unsubscr...@googlegroups.com.
> To post to this group, send email to sympy@googlegroups.com.
> Visit this group at http://groups.google.com/group/sympy.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/sympy/55A52B99.70000%40durchholz.org.
>
> For more options, visit https://groups.google.com/d/optout.
>
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sympy/CAKgW%3D6J%3DMKY8%2B2m5K6sJw7L7for-ynWdtV8JfLFumJU%2BAitPQQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
