Mimic gitflow about boost2git

[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 [email protected]:

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 [email protected] wrote:

On Sun, Oct 20, 2013 at 3:10 PM, Niall Douglas [email protected]:

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.