gnucash-htdocs branch master updated. svn_last-505-ga286032

[Geert Janssens]

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