[git] Near future.. How do we deal with git-native libraries?

newer
Proposal: Vector-like container,...

older
[asio] Bug: Handlers execute on...

Rene Rivera

1 Dec 2013 1 Dec '13

9:54 p.m.

As the owner of the Predef library which exists originally in github and not svn.. I'm wondering about some things for the near future (as in this coming week): 1. Where will the git repo live for a library? Will the repo need to stay in the boostorg organization? Or is it possible/desirable to use the existing repo that's part of my user account? 2. I notice that there's a ".gitattributes" file in the svn imported version of the Predef repo. Will I need to add that file to my actual Predef git repo? And if so, is there a single canonical version of that file I should use? And a followup.. In the future if that file changes, does it need to change for all repos consistently? Rene. -- -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo

Show replies by date

Beman Dawes

2 Dec 2 Dec

8:21 a.m.

On Sun, Dec 1, 2013 at 4:54 PM, Rene Rivera wrote:

...

As the owner of the Predef library which exists originally in github and not svn.. I'm wondering about some things for the near future (as in this coming week):

1. Where will the git repo live for a library? Will the repo need to stay in the boostorg organization?

Yes. The theory being that if a maintainer goes missing, Boost doesn't lose control of the repo. Also, the thought was it would be easier to get going that way even if eventually we figured out policy for repos not hosted by boostorg.

...

Or is it possible/desirable to use the existing repo that's part of my user account?

We need to have a discussion of this, but IIUC we could create the boostorg repo for a new library by forking a github library such as yours. I haven't given any thought to the pros and cons of that. 2. I notice that there's a ".gitattributes" file in the svn imported

...

version of the Predef repo. Will I need to add that file to my actual Predef git repo? And if so, is there a single canonical version of that file I should use? And a followup.. In the future if that file changes, does it need to change for all repos consistently?

Good questions, but I don't know the plans for .gitattributes. --Beman

Daniel James

8:44 a.m.

On 2 December 2013 08:21, Beman Dawes wrote:

...

...
Or is it possible/desirable to use the existing repo that's part of my user account?

We need to have a discussion of this, but IIUC we could create the boostorg repo for a new library by forking a github library such as yours. I haven't given any thought to the pros and cons of that.

This has been discussed in the past. The existing repo will need to remain as the super module refers to the hash values of its commits. The suggested fix was to combine the two repos, since a git repo can contain two separate trees. The old branches will need to be kept alive by tagging them. I'd rather have kept the two separate by using a different name for the converted repo (e.g. svn-predef), but no one agreed with me.

Rene Rivera

7:47 p.m.

On Mon, Dec 2, 2013 at 2:44 AM, Daniel James wrote:

...

On 2 December 2013 08:21, Beman Dawes wrote:

...
...
Or is it possible/desirable to use the existing repo that's part of my user account?

We need to have a discussion of this, but IIUC we could create the boostorg repo for a new library by forking a github library such as yours. I haven't given any thought to the pros and cons of that.

This has been discussed in the past. The existing repo will need to remain as the super module refers to the hash values of its commits. The suggested fix was to combine the two repos, since a git repo can contain two separate trees. The old branches will need to be kept alive by tagging them.

I'd rather have kept the two separate by using a different name for the converted repo (e.g. svn-predef), but no one agreed with me.

Since it seems that we need to BoostOrg repo.. My preference would be to slam the BoostOrg one with my canonical repo and only keep the BoostOrg repo around. Since the canonical one has more, and more accurate, history than the BoostOrg one. But I don't know what the ramifications of such a move are. -- -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo

Daniel James

3 Dec 3 Dec

8:58 a.m.

On 2 December 2013 19:47, Rene Rivera wrote:

...

On Mon, Dec 2, 2013 at 2:44 AM, Daniel James wrote:

...
This has been discussed in the past. The existing repo will need to remain as the super module refers to the hash values of its commits. The suggested fix was to combine the two repos, since a git repo can contain two separate trees. The old branches will need to be kept alive by tagging them.

I'd rather have kept the two separate by using a different name for the converted repo (e.g. svn-predef), but no one agreed with me.

Since it seems that we need to BoostOrg repo.. My preference would be to slam the BoostOrg one with my canonical repo and only keep the BoostOrg repo around. Since the canonical one has more, and more accurate, history than the BoostOrg one. But I don't know what the ramifications of such a move are.

Sorry, I don't understand what you mean. Although what I wrote above wasn't particularly comprehensible either. What I was trying to get at is something like the following which stores both histories in a single repo, but keeps them separate and makes yours the main branches. Afterwards the super-repo will need to be updated accordingly. Maybe someone has a better idea? # Create clone containing both repos: git clone git@github.com:boostorg/predef.git cd predef git remote add grafik git@github.com:grafikrobot/boost-predef.git git fetch grafik # Save old branches, so old checkouts of the main module # will still work: git tag svn-develop origin/develop git tag svn-master origin/master git push --tags # Replace master, keeping some files from the old repo: # (-B overwrite the local branch) git checkout grafik/master -B master git checkout svn-master -- .gitattributes index.html git commit -m "Add files required for boost" git push --force origin master # Replace develop with master as well, # as grafik/predef doesn't have a develop branch git checkout -b develop git push --force origin develop

Cox, Michael

11:05 a.m.

On Tue, Dec 3, 2013 at 1:58 AM, Daniel James wrote:

...

On 2 December 2013 19:47, Rene Rivera wrote:

...
On Mon, Dec 2, 2013 at 2:44 AM, Daniel James wrote:

...
This has been discussed in the past. The existing repo will need to remain as the super module refers to the hash values of its commits. The suggested fix was to combine the two repos, since a git repo can contain two separate trees. The old branches will need to be kept alive by tagging them.

I'd rather have kept the two separate by using a different name for the converted repo (e.g. svn-predef), but no one agreed with me.

Since it seems that we need to BoostOrg repo.. My preference would be to slam the BoostOrg one with my canonical repo and only keep the BoostOrg repo around. Since the canonical one has more, and more accurate, history than the BoostOrg one. But I don't know what the ramifications of such a move are.

Sorry, I don't understand what you mean. Although what I wrote above wasn't particularly comprehensible either. What I was trying to get at is something like the following which stores both histories in a single repo, but keeps them separate and makes yours the main branches. Afterwards the super-repo will need to be updated accordingly. Maybe someone has a better idea?

# Create clone containing both repos: git clone git@github.com:boostorg/predef.git cd predef git remote add grafik git@github.com:grafikrobot/boost-predef.git

I'm assuming you're the lead (only?) developer for this library. As the library maintainer you would integrate changes from other contributors into your repo under github.com/grafikrobot (or if you work on other open source projects, you may want to create an organization under your account, e.g. grafikrobot-boost to do all your boost work. See Creating a new organization accounthttps://help.github.com/articles/creating-a-new-organization-account--2. I'm going to assume you've created a grafikrobot-boost organization under your user account. If not, then do this under grafikrobot. So under grafikrobot-boost, fork the github.com/boostorg/predef repository: - Go to http://github.com/boostorg/predef and click on the fork button in the upper right of the window. - In the pop-up window select grafikrobot-boost to create the fork. - Now your new forked repo is linked to the official boostorg/predef repo as a fork and you can submit pull requests to boostorg/predef. The Boost release manager will than pull in your changes from the develop branch of grafikrobot-boost/predef. Follow the above steps for the github.com/boostorg/boost respository. Now that you have your new predef and boost repo under grafik-boost, execute the following commands on your PC: git clone --recursive -o upstream -b develop https://github.com/boostorg/boost git remote add -b grafikrobot/develop origin git@github.com: grafikrobot-boost/boost git fetch origin "+refs/heads/*:refs/heads/grafik/*" git fetch upstream "+refs/heads/*:refs/heads/*" cd libs/predef git remote add -b grafikrobot/develop origin git@github.com: grafikrobot-boost/predef git fetch origin "+refs/heads/*:refs/heads/grafik/*" git fetch upstream "+refs/heads/*:refs/heads/*" You now have the boost and predef repos connected to the official repos under github.com/boostorg using the upstream remote and connected to your public repos under github.com/grafikrobot-boost using the origin remote. The local branch develop has the latest changes from boostorg. The local branch grafik/develop is equivalent to the develop from boostorg. Now we add a remote to retrieve the changes you want to add to the grafik/develop branch from grafikrobot/boost-predef into temp/develop: git remote add -b temp/develop temp git@github.com:grafikrobot/boost-predef git fetch temp "+refs/heads/*:refs/heads/temp/*" You now have a temp/develop branch that contains your new changes. Now merge the changes in temp/develop into grafik/develop and push to your public repo: git checkout grafik/develop git merge temp/develop git commit -a git push origin grafik/develop Now you have to add and commit a submodule ref in the super-repository boost: cd ../.. git add . git commit -m"Update submodule ref to point to latest commits in predef." git push origin grafik/develop Now that you have all the changes in grafikrobot-boost, go to github.com/boostorg/predef and github.com/boostorg/boost and submit pull requests from the branches grafik/develop in the boost and predef repositories under github.com/grafikrobot-boost. You can now delete the temp remote and temp/* local branches from the repositories on your PC. Also, you can delete the github.com/grafikrobot/boost-predef repository ( github.com/grafik-boost/predef is your new public repository). You can pull from the upstream remote any changes in the boost repo by other developers. Since all contributions to predef should flow through you, you probably won't need to pull updates from the upstream remote pointing to github.com/grafikrobot-boost/predef repository. Michael

Daniel James

11:36 a.m.

On 3 December 2013 11:05, Cox, Michael wrote:

...

- Now your new forked repo is linked to the official boostorg/predef repo as a fork and you can submit pull requests to boostorg/predef. The Boost release manager will than pull in your changes from the develop branch of grafikrobot-boost/predef.

I believe the plan is for everyone to have write access to the repositories that they maintain and to update them themselves.

Cox, Michael

6:59 p.m.

On Tue, Dec 3, 2013 at 4:36 AM, Daniel James wrote:

...

On 3 December 2013 11:05, Cox, Michael wrote:

...
- Now your new forked repo is linked to the official boostorg/predef repo as a fork and you can submit pull requests to boostorg/predef.

The

...
Boost release manager will than pull in your changes from the develop branch of grafikrobot-boost/predef.

I believe the plan is for everyone to have write access to the repositories that they maintain and to update them themselves.

I was not aware of that. I expected the release manager(s) to only have write access and library maintainers to submit pull requests to them. So ignore my last few posts :-). Michael

...

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Beman Dawes

9:46 p.m.

On Tue, Dec 3, 2013 at 1:59 PM, Cox, Michael wrote:

...

On Tue, Dec 3, 2013 at 4:36 AM, Daniel James wrote:

...
On 3 December 2013 11:05, Cox, Michael wrote:

...
- Now your new forked repo is linked to the official boostorg/predef repo as a fork and you can submit pull requests to boostorg/predef.

The

...
Boost release manager will than pull in your changes from the develop branch of grafikrobot-boost/predef.

I believe the plan is for everyone to have write access to the repositories that they maintain and to update them themselves.

I was not aware of that. I expected the release manager(s) to only have write access and library maintainers to submit pull requests to them. So ignore my last few posts :-).

Only release managers have write access to the boost super-project. So they can still control quality in terms of what goes into official Boost releases. OTOH, Individual libraries can do their own releases whenever they want to. This decoupling is is part of why we hope that the Modular Boost structure will scale up to much larger numbers of libraries. --Beman

Cox, Michael

4 Dec 4 Dec

7:13 a.m.

On Tue, Dec 3, 2013 at 2:46 PM, Beman Dawes wrote:

...

On Tue, Dec 3, 2013 at 1:59 PM, Cox, Michael
...
wrote:

...
On Tue, Dec 3, 2013 at 4:36 AM, Daniel James wrote:

...
On 3 December 2013 11:05, Cox, Michael wrote:

...
- Now your new forked repo is linked to the official

boostorg/predef

...
repo as a fork and you can submit pull requests to boostorg/predef. The Boost release manager will than pull in your changes from the develop branch of grafikrobot-boost/predef.

I believe the plan is for everyone to have write access to the repositories that they maintain and to update them themselves.

I was not aware of that. I expected the release manager(s) to only have write access and library maintainers to submit pull requests to them. So ignore my last few posts :-).

Only release managers have write access to the boost super-project. So they can still control quality in terms of what goes into official Boost releases. OTOH, Individual libraries can do their own releases whenever they want to. This decoupling is is part of why we hope that the Modular Boost structure will scale up to much larger numbers of libraries.

There may be a problem using submodules if library/tool developers don't have write access to the boost super-project. The "usual" process when using git submodules is that when making a commit to a submodule, you also make a commit in the super-project to add a submodule reference so that when anyone recursively clones or "submodule update"'s, all the submodules point to the latest changes. Is Boost not going to follow the "usual" process? If not, then developers need to know that after doing the recursive clone, they need to run "git submodule foreach git checkout develop" to point all the submodules to their latest changes. BTW, if the "usual" process is to be followed, I noticed libs/system and libs/multi_index don't have submodule ref commits in boost.git for their current HEADs. Also, noticed that tools/litre doesn't have a develop branch. Michael

...

--Beman

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Daniel James

9:40 a.m.

On 4 December 2013 07:13, Cox, Michael wrote:

...

There may be a problem using submodules if library/tool developers don't have write access to the boost super-project.

The "usual" process when using git submodules is that when making a commit to a submodule, you also make a commit in the super-project to add a submodule reference so that when anyone recursively clones or "submodule update"'s, all the submodules point to the latest changes. Is Boost not going to follow the "usual" process?

I think the plan is to automatically update the super project from the master and develop branches. Or maybe from the master and release branches (using git flow). But there's another thread discussing this, so it's best not to go into it here.

Joaquin M Lopez Munoz

9:49 p.m.

Cox, Michael writes:

...

BTW, if the "usual" process is to be followed, I noticed libs/system and libs/multi_index don't have submodule ref commits in boost.git for their current HEADs. Also, noticed that tools/litre doesn't have a develop branch.

Being both the author of Boost.MultiIndex and a total Git neophyte, could you please explain to me how this lack of ref commits affect me and whether I can fix it myself? Thank you! Joaquín M López Muñoz Telefónica Digital

Daniel James

11:56 p.m.

On 4 December 2013 21:49, Joaquin M Lopez Munoz wrote:

...

Cox, Michael writes:

...
BTW, if the "usual" process is to be followed, I noticed libs/system and libs/multi_index don't have submodule ref commits in boost.git for their current HEADs. Also, noticed that tools/litre doesn't have a develop branch.

Being both the author of Boost.MultiIndex and a total Git neophyte, could you please explain to me how this lack of ref commits affect me and whether I can fix it myself?

It means that when someone checks out the master project they don't get the latest versions of the submodules. I'm just updating the master project now. Hopefully I'm not stepping on anyone's toes by doing so.

Rene Rivera

3:48 a.m.

On Tue, Dec 3, 2013 at 2:58 AM, Daniel James wrote:

...

On 2 December 2013 19:47, Rene Rivera wrote:

...
On Mon, Dec 2, 2013 at 2:44 AM, Daniel James wrote:

...
This has been discussed in the past. The existing repo will need to remain as the super module refers to the hash values of its commits. The suggested fix was to combine the two repos, since a git repo can contain two separate trees. The old branches will need to be kept alive by tagging them.

I'd rather have kept the two separate by using a different name for the converted repo (e.g. svn-predef), but no one agreed with me.

Since it seems that we need to BoostOrg repo.. My preference would be to slam the BoostOrg one with my canonical repo and only keep the BoostOrg repo around. Since the canonical one has more, and more accurate, history than the BoostOrg one. But I don't know what the ramifications of such a move are.

Sorry, I don't understand what you mean. Although what I wrote above wasn't particularly comprehensible either. What I was trying to get at is something like the following which stores both histories in a single repo, but keeps them separate and makes yours the main

I think I understand that.. I can't "remove" the existing history (by replacing the repo with my other one) because the history is being used by tags. And hence the option you are proposing is to merge the two repos together and hiding away the SVN imported one. Which seems like a reasonable option for Predef since it doesn't have a long git history (but slightly longer and more detailed than the svn history).

...

branches. Afterwards the super-repo will need to be updated accordingly. Maybe someone has a better idea?

# Create clone containing both repos: git clone git@github.com:boostorg/predef.git cd predef git remote add grafik git@github.com:grafikrobot/boost-predef.git git fetch grafik

# Save old branches, so old checkouts of the main module # will still work: git tag svn-develop origin/develop git tag svn-master origin/master git push --tags

# Replace master, keeping some files from the old repo: # (-B overwrite the local branch) git checkout grafik/master -B master git checkout svn-master -- .gitattributes index.html git commit -m "Add files required for boost" git push --force origin master

# Replace develop with master as well, # as grafik/predef doesn't have a develop branch git checkout -b develop git push --force origin develop

I must confess I don't understand the git commands.. But I do understand your comments of them. Am I to assume you've mostly tried them? I ask because I'm ok blindly following them once. But will likely fall flat on my face if something goes wrong :-) -- -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo

Rene Rivera

4:26 a.m.

PS. I should say that it's rather important we come up with a good solution for people to follow on this as it will likely be the standard way to move newly accepted libraries into boost. On Tue, Dec 3, 2013 at 9:48 PM, Rene Rivera wrote:

...

On Tue, Dec 3, 2013 at 2:58 AM, Daniel James wrote:

...
On 2 December 2013 19:47, Rene Rivera wrote:

...
On Mon, Dec 2, 2013 at 2:44 AM, Daniel James wrote:

...
This has been discussed in the past. The existing repo will need to remain as the super module refers to the hash values of its commits. The suggested fix was to combine the two repos, since a git repo can contain two separate trees. The old branches will need to be kept alive by tagging them.

I'd rather have kept the two separate by using a different name for the converted repo (e.g. svn-predef), but no one agreed with me.

Since it seems that we need to BoostOrg repo.. My preference would be to slam the BoostOrg one with my canonical repo and only keep the BoostOrg repo around. Since the canonical one has more, and more accurate, history than the BoostOrg one. But I don't know what the ramifications of such a move are.

Sorry, I don't understand what you mean. Although what I wrote above wasn't particularly comprehensible either. What I was trying to get at is something like the following which stores both histories in a single repo, but keeps them separate and makes yours the main

I think I understand that.. I can't "remove" the existing history (by replacing the repo with my other one) because the history is being used by tags. And hence the option you are proposing is to merge the two repos together and hiding away the SVN imported one. Which seems like a reasonable option for Predef since it doesn't have a long git history (but slightly longer and more detailed than the svn history).

...
branches. Afterwards the super-repo will need to be updated accordingly. Maybe someone has a better idea?

# Create clone containing both repos: git clone git@github.com:boostorg/predef.git cd predef git remote add grafik git@github.com:grafikrobot/boost-predef.git git fetch grafik

# Save old branches, so old checkouts of the main module # will still work: git tag svn-develop origin/develop git tag svn-master origin/master git push --tags

# Replace master, keeping some files from the old repo: # (-B overwrite the local branch) git checkout grafik/master -B master git checkout svn-master -- .gitattributes index.html git commit -m "Add files required for boost" git push --force origin master

# Replace develop with master as well, # as grafik/predef doesn't have a develop branch git checkout -b develop git push --force origin develop

I must confess I don't understand the git commands.. But I do understand your comments of them. Am I to assume you've mostly tried them? I ask because I'm ok blindly following them once. But will likely fall flat on my face if something goes wrong :-)

-- -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo

-- -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo

Daniel James

9:36 a.m.

On 4 December 2013 04:26, Rene Rivera wrote:

...

PS. I should say that it's rather important we come up with a good solution for people to follow on this as it will likely be the standard way to move newly accepted libraries into boost.

This won't be a problem for new libraries, as they won't have subversion history to contend with.

Daniel James

9:35 a.m.

On 4 December 2013 03:48, Rene Rivera wrote:

...

I think I understand that.. I can't "remove" the existing history (by replacing the repo with my other one) because the history is being used by tags. And hence the option you are proposing is to merge the two repos together and hiding away the SVN imported one. Which seems like a reasonable option for Predef since it doesn't have a long git history (but slightly longer and more detailed than the svn history).

Yes, that's what I was saying.

...

...
branches. Afterwards the super-repo will need to be updated accordingly. Maybe someone has a better idea?

# Create clone containing both repos: git clone git@github.com:boostorg/predef.git cd predef git remote add grafik git@github.com:grafikrobot/boost-predef.git git fetch grafik

# Save old branches, so old checkouts of the main module # will still work: git tag svn-develop origin/develop git tag svn-master origin/master git push --tags

# Replace master, keeping some files from the old repo: # (-B overwrite the local branch) git checkout grafik/master -B master git checkout svn-master -- .gitattributes index.html git commit -m "Add files required for boost" git push --force origin master

# Replace develop with master as well, # as grafik/predef doesn't have a develop branch git checkout -b develop git push --force origin develop

I must confess I don't understand the git commands.. But I do understand your comments of them. Am I to assume you've mostly tried them? I ask because I'm ok blindly following them once. But will likely fall flat on my face if something goes wrong :-)

I just gave it another go, and it seems fine. If you want I'll do it for you.

Ahmed Charles

7 Dec 7 Dec

6:10 a.m.

New subject: [git] Near future.. How do we deal with git-native libraries?

...

Date: Wed, 4 Dec 2013 09:35:46 +0000 From: daniel@calamity.org.uk To: boost@lists.boost.org Subject: Re: [boost] [git] Near future.. How do we deal with git-native libraries?

On 4 December 2013 03:48, Rene Rivera wrote:

...
I think I understand that.. I can't "remove" the existing history (by replacing the repo with my other one) because the history is being used by tags. And hence the option you are proposing is to merge the two repos together and hiding away the SVN imported one. Which seems like a reasonable option for Predef since it doesn't have a long git history (but slightly longer and more detailed than the svn history).

Yes, that's what I was saying.

...
...
branches. Afterwards the super-repo will need to be updated accordingly. Maybe someone has a better idea?

# Create clone containing both repos: git clone git@github.com:boostorg/predef.git cd predef git remote add grafik git@github.com:grafikrobot/boost-predef.git git fetch grafik

# Save old branches, so old checkouts of the main module # will still work: git tag svn-develop origin/develop git tag svn-master origin/master git push --tags

# Replace master, keeping some files from the old repo: # (-B overwrite the local branch) git checkout grafik/master -B master git checkout svn-master -- .gitattributes index.html git commit -m "Add files required for boost" git push --force origin master

# Replace develop with master as well, # as grafik/predef doesn't have a develop branch git checkout -b develop git push --force origin develop

I must confess I don't understand the git commands.. But I do understand your comments of them. Am I to assume you've mostly tried them? I ask because I'm ok blindly following them once. But will likely fall flat on my face if something goes wrong :-)

I just gave it another go, and it seems fine. If you want I'll do it for you.

Did this ever happen? Note, I'd think that merging the two histories together would result in a more seamless transition from the svn history to the git history rather than having two disjoint histories.

Daniel James

8:11 a.m.

On 7 December 2013 06:10, Ahmed Charles wrote:

...

Did this ever happen?

Not yet.

...

Note, I'd think that merging the two histories together would result in a more seamless transition from the svn history to the git history rather than having two disjoint histories.

There's not much advantage of having a seamless transition at this stage, so having a clean history for the repo is probably more useful in the long run.

Ahmed Charles

11:02 a.m.

New subject: [git] Near future.. How do we deal with git-native libraries?

...

Date: Sat, 7 Dec 2013 08:11:15 +0000 From: daniel@calamity.org.uk To: boost@lists.boost.org Subject: Re: [boost] [git] Near future.. How do we deal with git-native libraries?

On 7 December 2013 06:10, Ahmed Charles wrote:

...
Did this ever happen?

Not yet.

...
Note, I'd think that merging the two histories together would result in a more seamless transition from the svn history to the git history rather than having two disjoint histories.

There's not much advantage of having a seamless transition at this stage, so having a clean history for the repo is probably more useful in the long run.

The common courtesy in git is to do only fast-forward commits on public branches, hence my comment. Obviously, with good enough reasons, you can always decide to not do this.

Rene Rivera

3 Jan 3 Jan

3:58 a.m.

On Wed, Dec 4, 2013 at 3:35 AM, Daniel James wrote:

...

On 4 December 2013 03:48, Rene Rivera wrote:

...
I think I understand that.. I can't "remove" the existing history (by replacing the repo with my other one) because the history is being used

by

...
tags. And hence the option you are proposing is to merge the two repos together and hiding away the SVN imported one. Which seems like a reasonable option for Predef since it doesn't have a long git history (but slightly longer and more detailed than the svn history).

Yes, that's what I was saying.

...
...
branches. Afterwards the super-repo will need to be updated accordingly. Maybe someone has a better idea?

# Create clone containing both repos: git clone git@github.com:boostorg/predef.git cd predef git remote add grafik git@github.com:grafikrobot/boost-predef.git git fetch grafik

# Save old branches, so old checkouts of the main module # will still work: git tag svn-develop origin/develop git tag svn-master origin/master git push --tags

# Replace master, keeping some files from the old repo: # (-B overwrite the local branch) git checkout grafik/master -B master git checkout svn-master -- .gitattributes index.html git commit -m "Add files required for boost" git push --force origin master

# Replace develop with master as well, # as grafik/predef doesn't have a develop branch git checkout -b develop git push --force origin develop

I must confess I don't understand the git commands.. But I do understand your comments of them. Am I to assume you've mostly tried them? I ask because I'm ok blindly following them once. But will likely fall flat on my face if something goes wrong :-)

I just gave it another go, and it seems fine. If you want I'll do it for you.

Thanks Daniel for the procedure.. I mostly followed it (I had after the fact created a develop branch so both replacements steps where the same) and it seems to have worked. Just waiting to see if the super commit bot will update to the new branches. -- -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo

Beman Dawes

4 Jan 4 Jan

2:34 p.m.

On Thu, Jan 2, 2014 at 10:58 PM, Rene Rivera wrote:

...

Thanks Daniel for the procedure.. I mostly followed it (I had after the fact created a develop branch so both replacements steps where the same) and it seems to have worked. Just waiting to see if the super commit bot will update to the new branches.

I've captured Daniel's procedure at https://svn.boost.org/trac/boost/wiki/NewLibFromGit Comments and corrections appreciated. Thanks, --Beman

Daniel James

8:41 p.m.

On 4 January 2014 14:34, Beman Dawes wrote:

...

On Thu, Jan 2, 2014 at 10:58 PM, Rene Rivera wrote:

...
Thanks Daniel for the procedure.. I mostly followed it (I had after the fact created a develop branch so both replacements steps where the same) and it seems to have worked. Just waiting to see if the super commit bot will update to the new branches.

I've captured Daniel's procedure at https://svn.boost.org/trac/boost/wiki/NewLibFromGit

Comments and corrections appreciated.

It isn't appropriate for new libraries. It's just for a library that was in subversion, but was really using git already. I think the only examples are predef and odeint. We should sort out odeint very soon.

Karsten Ahnert

9:06 p.m.

...

It isn't appropriate for new libraries. It's just for a library that was in subversion, but was really using git already. I think the only examples are predef and odeint. We should sort out odeint very soon.

Sorry, what do you mean by sort out? Should I try to apply the above procedure for creating the branch to the boostorg/odeint repo?

Daniel James

9:16 p.m.

On 4 January 2014 21:06, Karsten Ahnert wrote:

...

...
It isn't appropriate for new libraries. It's just for a library that was in subversion, but was really using git already. I think the only examples are predef and odeint. We should sort out odeint very soon.

Sorry, what do you mean by sort out?

Sort out what how we're going to import odeint from your git repo into boost's.

...

Should I try to apply the above procedure for creating the branch to the boostorg/odeint repo?

Not yet, the problem is that you're currently using a different repository layout to the boost submodules. It's up to you how you want to approach that, if you're happy to change the module layout then that's simplest for us. But if that's a problem we'll have to work out another way.

Karsten Ahnert

9:22 p.m.

On 01/04/2014 10:16 PM, Daniel James wrote:

...

On 4 January 2014 21:06, Karsten Ahnert wrote:

...
...
It isn't appropriate for new libraries. It's just for a library that was in subversion, but was really using git already. I think the only examples are predef and odeint. We should sort out odeint very soon.

Sorry, what do you mean by sort out?

Sort out what how we're going to import odeint from your git repo into boost's.

...
Should I try to apply the above procedure for creating the branch to the boostorg/odeint repo?

Not yet, the problem is that you're currently using a different repository layout to the boost submodules. It's up to you how you want to approach that, if you're happy to change the module layout then that's simplest for us. But if that's a problem we'll have to work out another way.

I don't think it is a big problem for us to change our module layout since odeint is header-only. There are users which use our github version, but it should no be very difficult for them to change to the new module structure, since it just an adjustment of the include path. I think that's the better way since both repositories should be more or less equal.

...

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Daniel James

9:32 p.m.

On 4 January 2014 21:22, Karsten Ahnert wrote:

...

On 01/04/2014 10:16 PM, Daniel James wrote:

...
On 4 January 2014 21:06, Karsten Ahnert wrote:

...
...
It isn't appropriate for new libraries. It's just for a library that was in subversion, but was really using git already. I think the only examples are predef and odeint. We should sort out odeint very soon.

Sorry, what do you mean by sort out?

Sort out what how we're going to import odeint from your git repo into boost's.

...
Should I try to apply the above procedure for creating the branch to the boostorg/odeint repo?

Not yet, the problem is that you're currently using a different repository layout to the boost submodules. It's up to you how you want to approach that, if you're happy to change the module layout then that's simplest for us. But if that's a problem we'll have to work out another way.

I don't think it is a big problem for us to change our module layout since odeint is header-only. There are users which use our github version, but it should no be very difficult for them to change to the new module structure, since it just an adjustment of the include path. I think that's the better way since both repositories should be more or less equal.

Ok, that would be good. You also need to get write access, can you open an admin ticket at: https://github.com/boostorg/admin/issues

Karsten Ahnert

5 Apr 5 Apr

8:55 p.m.

...

Sort out what how we're going to import odeint from your git repo into boost's.

...
Should I try to apply the above procedure for creating the branch to the boostorg/odeint repo?

Not yet, the problem is that you're currently using a different repository layout to the boost submodules. It's up to you how you want to approach that, if you're happy to change the module layout then that's simplest for us. But if that's a problem we'll have to work out another way.

Sorry for the late reply. I was not able to work on this during the last weeks until now. I have made now the necessary changes in the repository layout for boost. At least in a testing branch. I have also merged this changes into a testing branch of the official boost repo of odeint. I added our library as a remote (odeint_root) and did git reset --hard odeint_root/boost_integ This "destroys" the history. But I think in this case this is not so bad, since the real history is in the github version instead of the boost version. It seems to work for me. At least all tests are running. How do we proceed now? I could merge the changes into the develop branch. Are the regression tests running somewhere, such that I could check that my changes are really ok?

Daniel James

9:13 p.m.

On 5 April 2014 21:55, Karsten Ahnert wrote:

...

I have made now the necessary changes in the repository layout for boost. At least in a testing branch. I have also merged this changes into a testing branch of the official boost repo of odeint. I added our library as a remote (odeint_root) and did

git reset --hard odeint_root/boost_integ

This "destroys" the history. But I think in this case this is not so bad, since the real history is in the github version instead of the boost version. It seems to work for me. At least all tests are running.

I'm afraid we'll need to keep the history so that clones of older versions of the super project will still work. But we can do that by tagging the last version of the old master and develop, so it won't have to be merged into the main branches' histories. This will be disruptive for anyone who uses 'git pull' to update the module, but hopefully this will be the last of such changes.

...

How do we proceed now? I could merge the changes into the develop branch. Are the regression tests running somewhere, such that I could check that my changes are really ok?

The super project is automatically updated to the lastest develop/master versions of every submodule. The odeint test results are at: http://www.boost.org/development/tests/develop/developer/numeric-odeint.html

Rene Rivera

4 Jan 4 Jan

9:24 p.m.

On Sat, Jan 4, 2014 at 2:41 PM, Daniel James wrote:

...

On 4 January 2014 14:34, Beman Dawes wrote:

...
On Thu, Jan 2, 2014 at 10:58 PM, Rene Rivera wrote:

...
Thanks Daniel for the procedure.. I mostly followed it (I had after the fact created a develop branch so both replacements steps where the same) and it seems to have worked. Just waiting to see if the super commit bot will update to the new branches.

I've captured Daniel's procedure at https://svn.boost.org/trac/boost/wiki/NewLibFromGit

Comments and corrections appreciated.

It isn't appropriate for new libraries. It's just for a library that was in subversion, but was really using git already. I think the only examples are predef and odeint. We should sort out odeint very soon.

A similar procedure could be appropriate if the branches that the project has are not the ones mandated by Boost. But, otherwise it's for libraries with both SVN and GIT histories. For new ones it looks like there's a simpler github option to just transfer ownership of the repo directly from one user to another. -- -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo

Beman Dawes

3 Dec 3 Dec

1:39 p.m.

On Mon, Dec 2, 2013 at 2:47 PM, Rene Rivera wrote:

...

On Mon, Dec 2, 2013 at 2:44 AM, Daniel James wrote:

...
On 2 December 2013 08:21, Beman Dawes wrote:

...
...
Or is it possible/desirable to use the existing repo that's part of my user account?

We need to have a discussion of this, but IIUC we could create the boostorg repo for a new library by forking a github library such as yours. I haven't given any thought to the pros and cons of that.

This has been discussed in the past. The existing repo will need to remain as the super module refers to the hash values of its commits. The suggested fix was to combine the two repos, since a git repo can contain two separate trees. The old branches will need to be kept alive by tagging them.

I'd rather have kept the two separate by using a different name for the converted repo (e.g. svn-predef), but no one agreed with me.

Since it seems that we need to BoostOrg repo.. My preference would be to slam the BoostOrg one with my canonical repo and only keep the BoostOrg repo around. Since the canonical one has more, and more accurate, history than the BoostOrg one. But I don't know what the ramifications of such a move are.

I'm having trouble understanding this discussion because of the imprecise terminology. By "BoostOrg repo" do you mean the GitHub boostorg repo? What do you mean by "slam"? "fork into"? Until exact steps are proposed, it is hard to know how history will be affected. --Beman

Niall Douglas

2 Dec 2 Dec

3:39 p.m.

On 2 Dec 2013 at 3:21, Beman Dawes wrote:

...

2. I notice that there's a ".gitattributes" file in the svn imported

...
version of the Predef repo. Will I need to add that file to my actual Predef git repo? And if so, is there a single canonical version of that file I should use? And a followup.. In the future if that file changes, does it need to change for all repos consistently?

Good questions, but I don't know the plans for .gitattributes.

I can speculate usefully :) Every git repo should have a .gitattributes period to sanitise the commits. Such a .gitattributes would look somewhat like the one provided by Boost, so you might as well use that one. Later on I think it very likely a script might scan all pull requests to ensure their commits were made using the canonical Boost .gitattributes, and if they weren't to refuse the pull request. I would assume that sometime not long from now the .gitattributes for all Boost git repos will be updated at once by Boost admin, so when you go to push to the Boost fork of your repo, git will remind you to merge updates and redo the push. If of course you just use the Boost fork of the repo directly instead of keeping a clone, if the above comes to pass you shouldn't need to ever worry about .gitattributes being stale. I would assume that once a library joins Boost, it would become normal to use the Boost copy, not your own private copy, so the issue becomes moot. Niall -- Currently unemployed and looking for work. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/

3872

Age (days ago)

3997

Last active (days ago)

List overview

Download

31 comments

9 participants

participants (9)

Ahmed Charles
Beman Dawes
Cox, Michael
Daniel James
Daniel James
Joaquin M Lopez Munoz
Karsten Ahnert
Niall Douglas
Rene Rivera