Thats terrible advice. Rebasing always makes it harder to keep multiple branches conflict-free. The only advantage of rebasing are easier-to-understand logs.
On Sunday, December 21, 2014 4:22:02 AM UTC+1, Nathann Cohen wrote: > > Hello Simon ! > > If I did not misunderstand your post, I think that Vincent and I faced the > same problems some time ago when we implemented a lot of combinatorial > tickets at once. > > If it told me anything, it is that when working in parallel with several > tickets which depend on each other, I should: > > 1) Always make sure that the dependency order is total (i.e. linear), even > if at first it does not seem mandatory > > 2) Rebase the tickets (rewriting the history) on their parent, and NOT > merge them with it > > This, because when you have 5 tickets depending on each other and the > lower one change, if you rebase i on i-1 you end up with 5 new commits in > the last ticket; > > I believe that in your case it would also simplify those useless merge > conflicts. > > Soooo well.. Next time you have a branch A that just got updated and a > branch B that depends on it, try a "git checkout B; git rebase A" just to > see. It will rewrite B's history, but honestly 99% of the time you are the > only one who uses your commits ^^; > > Nathann > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
