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 bootstrap.sh is hard to move, it should be at the top
>> level.
>
> Why not:
>
> #!/bin/sh
> exec submodule/booststrap_impl.sh
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.
Thanks,
Volodya