Boost logo

Boost :

Subject: Re: [boost] develop -> master merges
From: Vladimir Prus (ghost_at_[hidden])
Date: 2013-12-18 08:08:13

On 18.12.2013 16:59, Daniel James wrote:
> On 18 December 2013 12:27, Vladimir Prus <ghost_at_[hidden]> wrote:
>> It seems that is hard to move, it should be at the top
>> level.
> Why not:
> #!/bin/sh
> exec submodule/

That would create a module with two or three files in it. Putting this in tools/build is not really
appropriate, and that one is meant to be independent. It seems more trouble than doing cherry-pick.

>>> Another solution is to use Peter Dimov's suggested work flow, since
>>> with that master was merging in changes from develop. The
>>> latest/unstable branch could be automatically updated with changes
>>> from develop.
>> Yes, Peter's proposal will work just fine, and I think having superproject's
>> develop branch point and submodule master only sounds confusing, but is in
>> fact
>> fairly logical.
> We do need to have a better idea of how the branches are to be used,
> the current situation is unclear. I'm not sure git-flow is actually
> appropriate for the super project though, as the rolling release model
> doesn't quite fit. But this is a discussion for another thread.
>>> I don't agree with the reason for removing '-s theirs', but you can
>>> still use 'git merge -s ours master' from your release branch.
>> That would make the release branch be identical to master
> No it wouldn't. It's run from the release branch, so the release
> branch would stay exactly the same, then when merged into master it
> would not merge anything from master because all of master is already
> in its history (unless of course something was pushed to master after
> "merge -s ours" was run).

Yep, you're right. Speaking of which, "git merge master" might be better,
as that will actually merge any potentially unmerged changes from master.


Boost list run by bdawes at, gregod at, cpdaniel at, john at