On Tue, Jul 26, 2011 at 2: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
Sorry, meant to give a url here: https://github.com/asmeurer/sympy/commit/2ffedb50a3e0a4ae274d117ef87e09834ff8c98b Aaron Meurer > 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.
