On 18.12.2013 16:59, Daniel James wrote:
On 18 December 2013 12:27, Vladimir Prus
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