Hey Simon, Are you merging develop into every branch? If so, then you're doing things wrong. If you have A <- B, then you should merge develop into A, then merge A into B. If you get any more conflicts, then it's from the implementation of B. Also if you don't get any conflicts then any branch which depends on B should just merge into A (addressing Nathann's issue of minimizing commits).
Best, Travis On Sunday, December 21, 2014 7:31:27 AM UTC-8, Simon King wrote: > > Hi Volker, > > Am Sonntag, 21. Dezember 2014 15:40:53 UTC+1 schrieb Volker Braun: >> >> On Sunday, December 21, 2014 12:54:57 PM UTC+1, Simon King wrote: >>> >>> Concretely, someone found that a certain boilerplate function for >>> sequences >>> of bounded integers should better have a different name. I am using that >>> function in all subsequent tickets, and hence I *do* need to propagate >>> it >>> to every other branch. >>> >> >> No. You need to eventually update the other branches with the renamed >> function name, but there is no need to do it now. >> > > It would help if you would provide a definition of when a merge commit is > needed. I thought it is needed when I want to avoid duplicate work, or when > I want that my branches compile. > > >> Really, you are saying that your "bounded integers" api hasn't stabilized >> yet. >> > > When I continued with the later stages of my patch chain, I thought that > the api *had* stabilised. The api did change, because the reviewer thought > that the name "max_overlap" of a boilerplate function is unclear and should > be replaced by "startswith_tail". You can not predict such instabilities > that arise at some point of the workflow. > > > Unfortunately, because of some totally unrelated >>> problems (build errors with maxima, which is a program I really don't >>> need for my work), I *do* need to get recent commits from develop into >>> my work branch. >> >> >> Your original branches compiled, so the only problem is that you >> needlessly merged in the develop branch. >> > > Not quite. After an upgrade of my OS, Sage first did not compile. That's > actually the main reason why I wanted to merge develop (plus some other > commits from trac): It contains fixes that made Sage compile. Otherwise, I > could not continue to work. > > That's *my* definition of when a merge commit is needed: It is needed when > otherwise development would be stalled. > > >> Rebase is not a tool to arbitrarily move commits around, you should only >> use it to move the starting point of your branch forward. You'll probably >> have better luck with "merge --preserve-merges" in your case. >> > > Thank you for the pointer. I think that a tool to arbitrarily move commits > around would be very helpful, and I think that's one point where mercurial > was easier to use than git. > > Best regards, > Simon > > -- 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 sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
