I have found a way to do what I wanted. Most of my steps were ok, but I should not have used the master branch directly. A temporary branch to the rescue !
Here are the steps I used for the second attempt: 1. git checkout master 2. git checkout -b tmp 3. git merge -s ours beta -m "Reset beta back to master (but keeping history)" 4. git checkout beta 5. git reset --hard tmp 6. git branch -d tmp Step 2 is there to make sure the master branch itself is never changed. tmp will be the working branch for this operation. Step 3 discards any changes in beta and generates a new merge commit on the tmp branch. That's the commit we want as the HEAD for our future beta branch. So with steps 4 and 5 we force-move the beta head to this commit. Step 6 is just there to cleanup. That should work, unless someone sees problems I didn't think of ? Geert On Wednesday 29 May 2013 12:13:07 Geert Janssens wrote: > For those curious to what happened here: > This (and the next) push are part of an experiment to reset the beta branch > to the current master/trunk branch using git features. > > The following commands were executed: > 1. git checkout master > 2. git merge -s ours beta > (pushed the master branch to gitolite afterwards) > 3. git checkout beta > 4. git reset --hard master > (pushed beta branch afterwards > > Some background for the experiment: > In svn we had a trunk branch and a beta branch. The trunk branch represents > the live website at www.gnucash.org. The beta branch is a branch for > testing, visible at www.gnucash.org/beta. > > The htdocs README file states that beta should be updated to whatever trunk > is before starting any serious experiments. In svn this was typically done > by copying the current data from the most recent trunk commit to beta and > check this in. That sort of works for the limited use case of the website, > but svn has no idea you actually reset beta to trunk. The two branches > remain to separate, independent branches as far as svn is concerned. > > I believe it is more beneficial if the revision history reflects your > intended actions and so I tried if this could be done in git. This > experiment is one attempt to have the git history reflect that beta was > reset to master. If you look at the history in git at this moment, it will > show you that we have the two branches merged together, meaning they point > at the same commit currently. > > I'm not fully happy with this though. What we lose here is the knowledge of > which of the two merged branches was master and which one was beta. Suppose > for some reason we have to revert back to a commit where the two were not > merged together yet. Which branch was master and which one was beta ? > > So I'm wondering how to deal with this. Add a tag to the last commits right > before merging ? Use a different merge strategy that allows us to keep two > independent branches ? Ideally a 'git merge -s theirs master' on the beta > branch would do that, but that doesn't seem to exist. > > Geert _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
