Mimic gitflow

[purpleKarrot]

• [ ] map 'trunk' to 'develop'
• [ ] make 'develop' the default branch
• [ ] connect all tags to 'master'

[dabrahams]

@purpleKarrot, did you get Beman's query about this?

[ned14]

Niall at the GSoC mentors conference here. Me and the other Boost reps were discussing this last night over a lot of Google provided free beer, and we were thinking this:

• git lets you specify different submodule branches in .gitmodules for a branch, so develop branch can submodule the develop branch in other git repos. The problem here is when you merge from develop branch to master that the gitmodules will get overwritten, and people will keep forgetting to fix up back up after a merge.
• We noted that probably most library development will prefer to develop against the last stable or beta release, not bleeding edge. In this case every branch in fact wants to submodule master branch in any submodules.
• Really what we probably need is to supply some scripts (or more likely, extend b2 with git knowledge) which manage calling git for people, because managing linked branches by hand is probably brittle and tedious where you want some submodules with bleeding edge and other submodules with master. Perhaps some sort of user created config file in the root might let users set or override defaults.

Anyway maybe this is useful.

Niall

[Beman]

On Sun, Oct 20, 2013 at 3:10 PM, Niall Douglas notifications@github.comwrote:

Niall at the GSoC mentors conference here. Me and the other Boost reps were discussing this last night over a lot of Google provided free beer, and we were thinking this:

-

git lets you specify different submodule branches in .gitmodules for a branch, so develop branch can submodule the develop branch in other git repos. The problem here is when you merge from develop branch to master that the gitmodules will get overwritten, and people will keep forgetting to fix up back up after a merge.

We noted that probably most library development will prefer to develop against the last stable or beta release, not bleeding edge. In this case every branch in fact wants to submodule master branch in any submodules.

       I've been assuming that.

-

Really what we probably need is to supply some scripts (or more likely, extend b2 with git knowledge) which manage calling git for people, because managing linked branches by hand is probably brittle and tedious where you want some submodules with bleeding edge and other submodules with master. Perhaps some sort of user created config file in the root might let users set or override defaults.

       More and more, the Boost.Build folks are missing-in-action, so

I'd like to avoid anything that depends on changes to b2. Other than writing brief documentation, I'd really like to avoid adding more Boost maintained infrastructure.

Anyway maybe this is useful.

I'm definitely concerned about developer workflow under modular-boost, and that's why I asked for help in my recent "Documenting common modular boost workflows" post to the boost developers list. Maybe I wasn't blunt enough.

I'm not smart enough to come up with an easy-to-use and robust workfrow procedure as a thought experiment. Rather, some experimentation is needed, and asking others who have experience in a sub-module environment.

Thanks for thinking about workflow. Now that Dave and Daniel have given us the tools to do the conversion, we need to figure out how to best use git and modularization.

--Beman

[dabrahams]

On Oct 20, 2013, at 12:35 PM, Beman Dawes notifications@github.com wrote:

On Sun, Oct 20, 2013 at 3:10 PM, Niall Douglas notifications@github.comwrote:

Niall at the GSoC mentors conference here. Me and the other Boost reps were discussing this last night over a lot of Google provided free beer, and we were thinking this:

git lets you specify different submodule branches in .gitmodules for a branch, so develop branch can submodule the develop branch in other git repos. The problem here is when you merge from develop branch to master that the gitmodules will get overwritten,

If you mean .gitmodules, it doesn't get "overwritten;" it gets merged like any other file. But that said...

and people will keep forgetting

to fix up back up after a merge.

...AFAICT there's no reason to merge from develop in the master repo

We noted that probably most library development will prefer to develop against the last stable or beta release, not bleeding edge. In this case every branch in fact wants to submodule master branch in any submodules.

I've been assuming that.

Really what we probably need is to supply some scripts (or more likely, extend b2 with git knowledge) which manage calling git for people, because managing linked branches by hand is probably brittle and tedious where you want some submodules with bleeding edge and other submodules with master. Perhaps some sort of user created config file in the root might let users set or override defaults.

More and more, the Boost.Build folks are missing-in-action, so I'd like to avoid anything that depends on changes to b2. Other than writing brief documentation, I'd really like to avoid adding more Boost maintained infrastructure.

+1

If BB folks are MIA, maybe we need to be paying more attention to the CMake transition.

Anyway maybe this is useful.

I'm definitely concerned about developer workflow under modular-boost, and that's why I asked for help in my recent "Documenting common modular boost workflows" post to the boost developers list. Maybe I wasn't blunt enough.

I don't understand; I haven't read the post, but aren't we settled on git-flow?

I'm not smart enough to come up with an easy-to-use and robust workfrow procedure as a thought experiment. Rather, some experimentation is needed, and asking others who have experience in a sub-module environment.

Thanks for thinking about workflow. Now that Dave and Daniel have given us the tools to do the conversion, we need to figure out how to best use git and modularization.

git-flow has been our recommendation.

[ned14]

There seems to be a mailing list thread now happening on this, so I'll reply there. I will say this though: I think there is a huge difference between git flow as a process and git flow as a tool. The former I think is pretty braindead obvious apart from the inter-module workflow which will need working/evolved out. The latter, on the other hand, I think is not suited to Boost without some enhancement along the lines I was thinking of regarding b2.exe.

[purpleKarrot]

We concluded that renaming trunk to develop and branches/release to master is close enough.