On Tue, Jul 26, 2011 at 1:48 PM, Aaron Meurer <[email protected]> wrote: > Basically, it was like this: > > Mateusz had his polys branch, which had all his polys fixes. Every > time Mateusz wanted to be up to date with master, he rebased, and > created a new branch, polys2, polys3, etc. > > My branch from the start, integration, was based on one of these polys > branches. Then, when I wanted an update from one of the polys > branches, I would rebase over the newest polysn and renumber my > branch, integration2, and then integration3. But at this point, I > realized that rebasing is bad, and I should really not be doing it. > > So from that point on, I have never rebased the branch. This is why > my branch is called integration3 instead of just integration, btw. > > Probably if I had been rebasing over master instead of merging, this > would have been easier. But it would have been a false sense of easy. > This is because only half of the problems came from merge conflicts. > Other things were changes in the code. For example, as_basic was > renamed to as_expr. If I had rebased my branch over maser, not a > single commit in my history would have worked any more, because they > all use as_basic. So my choices would have been: > > 1. Go back and fix each commit in the history so that the tests pass. > This would have been even *harder* than the merge, I think. > > 2. Have a branch were bisecting is basically impossible. > > Another problem with rebasing is that sometimes changes are rebased > out, so you are left with commits that no longer change what they say > that change. I have commits like this in my branch, from when I was > rebasing. For example, > https://github.com/asmeurer/sympy/commit/4fbc80c12aae45f3a95e05740b62c4d546ada337, > which is from my original integration branch, does what it says, it > adds a check for the Python version. But this was backported to master > since my integration3 rebase, so now the corresponding commit > 2ffedb50a3e0a4ae274d117ef87e09834ff8c98b looks confusing, because the > part that does what the commit message says was rebased out. We also > see the problems of rebasing from the original polys merge (not > polys12, but the very first new polys branch). There are a bunch of > commits near the beginning of that branch for which sympy does not > import; you may have noticed these if you've tried bisecting back that > far. No doubt these worked originally, but the rebase broke them > somehow. > > This is why I believe you when you say your longest *rebase* was 1h or > work, because rebasing is easier in the sense that it hides these > problems from you. How long would it have taken if you had done the > right thing and merged instead?
My branch was messy, so I didn't want to have it "just merged". Also, I realized, that I think at one occasion, it took me more like 2h. Still though, not a big deal. >From what you say, I think that the conclusions are clear: 1) Mateusz should have just kept merging, and you should have kept merging to his branch. 2) The only time rebase is allowed is on your private branch, that nobody is using (yet). There is also another big problem --- when reviewing pull request, some people just rebase everything, and there is no way for me to check what changes they actually made. I think that a better practice is to do "the best" and submit a good solid pull request. And then just keep adding patches. (Unless it's so screwed up, that a good nice rebase is appropriate, for example when one is new to git, and one should do it at the end of the review, if nobody is using that branch yet) Ondrej -- 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.
