2011/7/26 Ondřej Čertík <[email protected]>: > 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 >
Also, you loose any commit comments, though I talked to the GitHub guys about this and they said they might fix it. But I agree. It's hard to do a diff against non-fast-forward commits. Aaron Meurer -- 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.
