From: Egon W. <ego...@gm...> - 2009-05-28 20:46:04
|
Hi all, just tried to update master for changes in cdk-1.2.x after the 1.2.2 release... and I failed. Originally, I had in mind that master would regularly be rebased on cdk-1.2.x, because the latter is sort of the base, with most of the bug fixing, and master with new stuff. However, that model fails, because master is public, and rebasing should not be used... it changes history of the branch, which makes it incompatible with checkouts made of master earlier. In short, rebasing breaks doing updates. What we Rajarshi and I did in the past time, is merge things... but that breaks at some point too... Rajarshi, could you please try merging the recent cdk-1.2.x changes into master? It failed for me... If that fails too, nothing is lost. Git rules in this area, and I think Git was right here, and we wrong. What 'master' really is, is a patch on top cdk-1.2.x and then we should consider it a patch indeed, and not a branch to be merged often. This is easily done with Git, by means of cherry-picking patches. A second option to clean history (make it linear again), is to, from now on, just cherry-pick bug fixes from cdk-1.2.x instead of pulling and/or merging. The latter is only feasible is all major new patches go into master, meaning that all new goodies will come with API changes too. Egon -- Post-doc @ Uppsala University http://chem-bla-ics.blogspot.com/ |
From: Rajarshi G. <raj...@gm...> - 2009-05-31 12:59:23
|
On May 28, 2009, at 4:45 PM, Egon Willighagen wrote: > > However, that model fails, because master is public, and rebasing > should not be used... it changes history of the branch, which makes it > incompatible with checkouts made of master earlier. In short, rebasing > breaks doing updates. I agree > What we Rajarshi and I did in the past time, is merge things... but > that breaks at some point too... Rajarshi, could you please try > merging the recent cdk-1.2.x changes into master? It failed for me... I just merged 1.2.x into master - the problem was some conflicts based on line endings (fixed) and the cdk.svnrev versus cdk.githash tags. I expect we'll see a few merge conflicts based on that last aspect - but they're easy to fix > A second option to clean history (make it linear again), is to, from > now on, just cherry-pick bug fixes from cdk-1.2.x instead of pulling > and/or merging. The latter is only feasible is all major new patches > go into master, meaning that all new goodies will come with API > changes too. I thought that was the plan all along - new stuff go into master and we only consider bug fixes to 1.2.x? In any case, if not, I think merges from 1.2.x to master, in general, a relatively easy. This is the first time I faced a conflict and it's an easy enough change ------------------------------------------------------------------- Rajarshi Guha <raj...@gm...> GPG Fingerprint: D070 5427 CC5B 7938 929C DD13 66A1 922C 51E7 9E84 ------------------------------------------------------------------- Q: What's polite and works for the phone company? A: A deferential operator. |
From: Egon W. <ego...@gm...> - 2009-06-02 09:12:03
|
On Sun, May 31, 2009 at 2:59 PM, Rajarshi Guha <raj...@gm...> wrote: > In any case, if not, I think merges from 1.2.x to master, in general, > a relatively easy. This is the first time I faced a conflict and it's > an easy enough change OK, good. Thanx for doing this; the merge did indeed involve svnrev here too, but I had more serious conflicts too... Egon -- Post-doc @ Uppsala University http://chem-bla-ics.blogspot.com/ |