Hi Brian, Matt and Addison, I think the discussion wandered a bit from the review.
1) Git history: Do you want to keep your history? Does the history bring any value to sympy? From what I understood, many times it doesn't import, or tests don't pass. So it seems to me there isn't really any value in keeping the history, is there? Depending on your answer, either: * create a set of two or three simple patches, that add the new functionality, use "git diff" and other things to see what was changed, or just this link: http://github.com/mattcurry/sympy/compare/sympy:master...mattcurry:hilbert2 as you can see, the real changes are really really simple (just adding things and mostly just adding new files). 2) doctests/documentation I would like to see this addressed, see my original email. Ondrej On Tue, Aug 17, 2010 at 5:21 PM, Aaron S. Meurer <asmeu...@gmail.com> wrote: > If you do decide to do rebasing, you should fix up some of the commit > messages. "DId [sic] nothing basically," "Not much," and "Nothing" aren't > very descriptive. Otherwise, try to do better in the future. You will be > cursing yourself later when you go back to fix a bug and can't tell what a > commit did because the only description given is "Fixed stuff." > > Basically, if you are going to have a rebase-free workflow, you have to do > commit messages right the first time. > > Aaron Meurer > > On Aug 17, 2010, at 1:06 PM, Vinzent Steinberg wrote: > >> 2010/8/17 Brian Granger <elliso...@gmail.com>: >>> On Tue, Aug 17, 2010 at 9:23 AM, Christian Muise >>> <christian.mu...@gmail.com> wrote: >>>> One thing that was pressed on me was the desire to have every commit run >>>> clean. Regardless of what point in the commit history, all tests should >>>> work, or at the very least the system should install (broken imports could >>>> alter this). I'm currently compiling an exhaustive execution of 'bin/test >>>> sympy/physics' for every one of the 140 commits, and many of them don't >>>> work. Many have import issues too, which throws a wrench into the mix. I've >>>> attached the output until the script I'm using runs into an infinite loop >>>> (it tries to keep unrolling the commit history), called output.txt. >>> >>> For complex code written by 3 people I don't think it is reasonable to >>> expect that every commit runs clean. There were many times that one >>> of us would commit partially working code that the others would pick >>> up and continue with. So I am sure there are many points in the >>> history where tests don't pass, code doesn't work or modules are not >>> even importable. >>> >>>> Now I don't think rebasing like mad is really an option -- I only had to >>>> deal with dozens of commits for my branch, not 140 :p -- but there needs to >>>> be some sort of amalgamation of the commits before it's brought into the >>>> trunk. A question for the rest of the community: What's the best way for >>>> Matt and Addison to go about achieving this? One single commit of the >>>> physics module? >>> >>> Trying to rebase these commits into a set of self contained commits >>> that all run cleanly will be nearly impossible. Also, with three of >>> us working on this code, the history of commits and merges is an >>> important part of the development process that I don't want to loose. >>> It is also important from the attribution and authorship standpoint. >>> If we squash all of these into a single commit, all of this >>> information is lost. >> >> Maybe not into a single commit, but it might make sense to squash some >> commits. For example "Started another commutator test.", "Fixed >> commutator doctest." and "Fixed Commutator issues" could probably be >> squashed without problems. But I agree that this is a daunting task >> for such a merge-heavy history. >> >> I'm impressed that you managed to work as 3 people on the same code >> base, I think you were able to use git to its fullest potential. :) >> >> Vinzent >> >> -- >> You received this message because you are subscribed to the Google Groups >> "sympy-patches" group. >> To post to this group, send email to sympy-patc...@googlegroups.com. >> To unsubscribe from this group, send email to >> sympy-patches+unsubscr...@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/sympy-patches?hl=en. >> > > -- > You received this message because you are subscribed to the Google Groups > "sympy-patches" group. > To post to this group, send email to sympy-patc...@googlegroups.com. > To unsubscribe from this group, send email to > sympy-patches+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/sympy-patches?hl=en. > > -- You received this message because you are subscribed to the Google Groups "sympy-patches" group. To post to this group, send email to sympy-patc...@googlegroups.com. To unsubscribe from this group, send email to sympy-patches+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy-patches?hl=en.
