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? So yes, I think if Mateusz had only merged with polys and I did the same with integration, then this would have been easier. As it is, whenever my branch gets in, there will be copies of commits, I think up to three or more in some places, because of the different versions of the polys that have been merged into my branch. On the other hand, even if I had totally screwed this merge up, I can still do git checkout HEAD~1 and get *exactly* the same commit that I had before the merge, and everything will still work exactly as it did before. I think that new git users have to learn how to rebase, because they don't know good commit habits and will have to go back and rewrite their history anyway. But once you learn good commit habits, and never have to squash any more or go back and rewrite bad commit messages, I think you should treat your commits as immutable; once they are made, you should never change them, and if you want to get new changes, you should only merge. Especially for large branches (for one commit branches, rebasing can be OK). This is another thing for you GSoC students to start considering. Once you consider yourselves "git gurus" (some of you are there and some of you aren't yet), you should consider to stop rebasing. Anyway, don't do it until you feel comfortable enough with git and with your commit habits that you will never want to edit a commit after you make it. But that actually doesn't take that long to get to that point. Aaron Meurer 2011/7/26 Ondřej Čertík <[email protected]>: > On Mon, Jul 25, 2011 at 3:24 PM, Aaron Meurer <[email protected]> wrote: >> Hi everyone. > > Can you describe what exactly you did with your branch? I.e.: > > 1) forked sympy in summer 2010, kept adding patches > 2) merged with polys1 branch > 3) polys12 (incompatible with polys1) merged to master > 4) merged with master (thus *conflicting* with polys1, merged to your branch) > > I think, that maybe all (?) your troubles were caused by merging the > polys1 with polys12, which were known to be incompatible, because > polys12 was rebased. In other words, maybe this is just a > manifestation of "never rebase, only merge", if people are using your > branch. > > I think that as long as the only thing that you do is "merge", things > should be much more easier. I have personally worked with some larger > branches too (~250 commits easily), and my experience so far is that > as long as there is no "double merge" (like polys1 and polys12), > things are quite simple. My longest rebase was I think 1h of work. > > 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. > > -- 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.
