Comments (6)
@purpleKarrot, did you get Beman's query about this?
from boost2git.
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
from boost2git.
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
from boost2git.
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.
from boost2git.
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.
from boost2git.
We concluded that renaming trunk
to develop
and branches/release
to master
is close enough.
from boost2git.
Related Issues (20)
- Remove redundant merge parents HOT 2
- Incremental conversion breaks .gitmodules HOT 2
- Lost submodules
- Remove redundant merge parents HOT 5
- Check for illegal branch hierarchies
- Report and/or correct for malformed rules HOT 1
- Port the submodule logic HOT 3
- Make sure empty commit elimination works with ancestry
- Optimize ancestry computation
- Make it incremental
- Deal with branch deletion
- Comment more of the code more thoroughly
- Do a lot more asynchronously
- Deal with executable files
- Deal with line endings
- Optimize merge discovery
- Address Warnings
- Record SVN revision numbers somewhere in Git HOT 1
- Inject a .gitattributes file HOT 1
- Translate symlinks
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from boost2git.