On Mon, Sep 30, 2013 at 11:21:03AM +0100, Lars Wirzenius wrote:
On Mon, Sep 30, 2013 at 11:17:14AM +0100, Jonathan Maw wrote:
> On Mon, Sep 30, 2013 at 11:12:54AM +0100, Lars Wirzenius wrote:
> > I am OK to merge this: merge the stratum changes into master of
> > baserock:baserock/morphs, and merge the newer glib into the branch in
> > upstream:glib that we currently use. if the glib merge fails and
> > cannot be easily fixed, create a new branch for the new version.
> The glib branch did not merge nicely (because it's not a fast-forward,
> since our current glib is from a stable branch), so I created a
> baserock/master branch. Last Friday, it was suggested that I could git
> merge using the merge-strategy 'theirs' (or alternatively 'ours'),
> I would like you input on whether I should try to merge or stick to
> the baserock/master branch I created.
I can live with either solution, though I would like it if we only had
one baserock/ branch we build from. Can you give merging with 'theirs'
a quick try and if it works, we'll do that?
I successfully merged against baserock/morph by emulating the
merge-strategy 'theirs' (by using the merge-strategy 'ours' backwards)
and it had an identical tree-sha1, thus having the same cache key.
I am pushing the merged baserock/morph branch now, and will submit the
xfce morphs for review (although I understand they have a low standard
for merging, since they're not first-class citizens)