On 12/08/2011 10:42 PM, William Hubbs wrote:
>> The cleanest way to do this this in Git may be:
>>
>> # git checkout master
>> # git merge -s theirs catalyst_2
>>
>> Haven't tested it though.
Just noticed that I mis-read the git-merge man page: "theirs" is an
option of the recursive merge strategy. Sorry.
> I checked it out with the folks on #git, and they are recommending
> that I rename catalyst_2 to master. I was given a series of commands to
> do this.
>
> The down side is that this will cause a forced update, so everyone will
> have to re-clone the repository.
Actually there is a way to do this *without* the downside that you describe.
The trick is to create a fake merge commit using git commit-tree to sort
of emulate merge strategy "theirs". The commit to make needs to:
- point to catalyst_2^{tree} as its content.
- have current catalyst_2 as its *first* parent in order to
- indicate where the data actually came from
- make commands like "git show HEAD^" descend into
the old catalyst_2 branch later as that's the content
that matters
- have current master as the second parent
(so people can keep working without trouble)
This time I tested it myself. This is what to do:
1) Make sure your local master and catalyst are *both* up to date.
2) # git checkout master
3) Create and merge a fake merge commit as defined above:
# git merge $(git commit-tree catalyst_2^{tree} \
-p catalyst_2 -p master \
<<<"Replace content on master with content from catalyst_2")
Again, the *order* of parents matters.
4) Confirm it went fine, e.g. this diff should now be empty:
# git diff master catalyst_2
> The target time I am considering for this is Monday, Dec 11, 0:00 utc.
> What that means is, everyone needs to have their changes pushed by then,
> then I'll make the change and send out an email here once I'm done.
> Then, you will have to re-clone your repositories.
>
> Any comments?
Please consider the alternative explained above.
What do you think?
Best,
Sebastian
