On Sun, Jun 26, 2011 at 08:26:13AM +0200, Sebastian Pipping wrote: > On 06/26/2011 07:03 AM, William Hubbs wrote: > > All, > > > > I checked out a local branch from master earlier today and rebased that > > on catalyst_2. Now that branch has over 100 commits, which will be the > > combination of everything on catilyst 2 and current master. > > > > So, how would you suggest we get that branch back out where everyone can > > see it? Do you want me to put it back out on master? It won't be a > > forced update, because I used rebase instead of merge. > > > > The only catch is I don't know how broken that will leave master. > > That sentence^^^ rings at least warning bells in my ears. I don't know > how well you know the code, how easy conflicts were to solve. What may > be important is that we have little (if any) test cases and that we get > little help from Python and Bash to detect breakage for us. If that > transition adds a pile of bugs that we'll find by chance somewhere next > year, that would be a problem.
The thing is, I think catalyst 3 is broken anyway; we need to hear from agaffney for sure what the status is. I know that the catalyst_2 branch is what releng is using to do their official builds. > Personally I may have chosen a road moving both branches towards each > other until their diff resolves to zero and than add a fake merge > commit. But that's dry theory - no idea if that would have worked well. > Plus I woulnd't make it alone and not in a few days or hours. I've never been able to figure out how to read merge commits when I use git log, so I try to stay away from them. My usual approach is to make master be where things come down from upstream, then I work on local branches. When I am ready to add something to master, I usually do this: git checkout master git pull # make sure master is up to date git rebase master mybranch # rebases "mybranch" changes on current master git checkout master git merge mybranch # this makes a fast-forward merge at this point git pull --rebase #update master with my changes at the end git push #add my changes to master > Please put them on a new branch (not master) while we're not sure ff the > resulting commits could or should be the future. Hmm, that will mean that all commits we are working on have to go to catalyst_2, the new branch, and master; I think that will make things even more complicated than they already are. I think want to try to find a way to bring the commits on catalyst_2 that are not on master over to master, so I may give it another shot before I do anything. William
pgpqvYJ1Jvo3m.pgp
Description: PGP signature
