I've spent some time looking at history of Boost.Build git repository, and I think I've got a fairly reasonable outcome. The problem statement is that in the converted repository, the top-level has nothing but a directory called 'v2', which is rather ugly. While it can be fixed with 'git mv', it would mean that 'git log file' will not show complete history unless the --follow option is passed, which is inconvenient. It appears that graphical tools don't like moves much either. There were already moves in SVN, so even now, running 'git log' on any file in engine/ won't return complete history without --follow. Further, at some older revision, there are two copies of what was jam code then. The most convenient solution for these problems is to edit history of the 'develop' branch, so that content of top-level directory matches what was in 'v2' in SVN, and so that content of 'engine' matches Jam sources through the years. This won't actually break any important references from the super-project, first because they presumably are only to master branch, and second, because the commit objects will be still retained in repository. I am not sure we need to rewrite the 'master' branch, as it's not used for day to day development. Now, as soon as we're rewriting history, it might be good idea to change directory structure to be more alike to the structure that other components have. The additional downside here is that the historical versions will not be fully functional - specifically it will break references from examples and tests to the rest of Boost.Build. But, I think it's worth the trouble - users can still obtain old, fully functional, versions from the tags, or master branch (yet another reason for it not to be rewritten), while developers will enjoy both clean directory structure and fully functional history on 'develop' branch. So, the way I'd most like Boost.Build develop branch to look is this: https://github.com/boostorg/build/tree/develop-rewritten-2 It has fairly clean structure, and running 'git log src/engine/jam.c' goes all the way to initial jam code import. The original post-conversion state is stored at converted-develop tag. Steven, Jurgen, what do you think? Any other concerns I have overlooked. I really would like to to get over git games, and declare the repository to be ready, so unless I'll hear objections by the end of Monday, I will force-push this to develop branch and adjust the super-project as necessary. If anybody wants to try at home, the rewriting was done like this: git filter-branch --prune-empty --tree-filter `pwd`/../rewrite.sh -f where 'rewrite.sh' is attached. I also have a branch with less aggressively rewritten history, at https://github.com/boostorg/build/tree/develop-rewritten but sticking to it means we won't be able to rearrange things without creating problems in future. Thanks, Volodya
On 12/14/2013 09:44 AM, Vladimir Prus wrote:
So, the way I'd most like Boost.Build develop branch to look is this:
Looks nice. Should debian be in a 'package' directory so that support for other package managers has an obvious place to live? michael -- Michael Caisse ciere consulting ciere.com
On 14.12.2013 21:51, Michael Caisse wrote:
On 12/14/2013 09:44 AM, Vladimir Prus wrote:
So, the way I'd most like Boost.Build develop branch to look is this:
Looks nice. Should debian be in a 'package' directory so that support for other package managers has an obvious place to live?
Good question. I think it is best to remove it. My understanding is that packagers for different Linux distributions prefer to keep their packaging in some local version control, where it's more convenient to update things. But in any case, history of the 'debian' directory is of relatively minor importance, we can move it later if we decide not to delete it. Thanks, Volodya
On 14.12.2013 21:44, Vladimir Prus wrote:
I've spent some time looking at history of Boost.Build git repository, and I think I've got a fairly reasonable outcome.
The problem statement is that in the converted repository, the top-level has nothing but a directory called 'v2', which is rather ugly. While it can be fixed with 'git mv', it would mean that 'git log file' will not show complete history unless the --follow option is passed, which is inconvenient. It appears that graphical tools don't like moves much either. There were already moves in SVN, so even now, running 'git log' on any file in engine/ won't return complete history without --follow. Further, at some older revision, there are two copies of what was jam code then.
The most convenient solution for these problems is to edit history of the 'develop' branch, so that content of top-level directory matches what was in 'v2' in SVN, and so that content of 'engine' matches Jam sources through the years. This won't actually break any important references from the super-project, first because they presumably are only to master branch, and second, because the commit objects will be still retained in repository. I am not sure we need to rewrite the 'master' branch, as it's not used for day to day development.
Now, as soon as we're rewriting history, it might be good idea to change directory structure to be more alike to the structure that other components have. The additional downside here is that the historical versions will not be fully functional - specifically it will break references from examples and tests to the rest of Boost.Build. But, I think it's worth the trouble - users can still obtain old, fully functional, versions from the tags, or master branch (yet another reason for it not to be rewritten), while developers will enjoy both clean directory structure and fully functional history on 'develop' branch.
So, the way I'd most like Boost.Build develop branch to look is this:
https://github.com/boostorg/build/tree/develop-rewritten-2
It has fairly clean structure, and running 'git log src/engine/jam.c' goes all the way to initial jam code import. The original post-conversion state is stored at converted-develop tag.
Steven, Jurgen, what do you think? Any other concerns I have overlooked. I really would like to to get over git games, and declare the repository to be ready, so unless I'll hear objections by the end of Monday, I will force-push this to develop branch and adjust the super-project as necessary.
I am gonna switch 'develop' to this version tomorrow morning, Moscow time. - Volodya
On 17.12.2013 22:33, Vladimir Prus wrote:
On 14.12.2013 21:44, Vladimir Prus wrote:
I've spent some time looking at history of Boost.Build git repository, and I think I've got a fairly reasonable outcome.
The problem statement is that in the converted repository, the top-level has nothing but a directory called 'v2', which is rather ugly. While it can be fixed with 'git mv', it would mean that 'git log file' will not show complete history unless the --follow option is passed, which is inconvenient. It appears that graphical tools don't like moves much either. There were already moves in SVN, so even now, running 'git log' on any file in engine/ won't return complete history without --follow. Further, at some older revision, there are two copies of what was jam code then.
The most convenient solution for these problems is to edit history of the 'develop' branch, so that content of top-level directory matches what was in 'v2' in SVN, and so that content of 'engine' matches Jam sources through the years. This won't actually break any important references from the super-project, first because they presumably are only to master branch, and second, because the commit objects will be still retained in repository. I am not sure we need to rewrite the 'master' branch, as it's not used for day to day development.
Now, as soon as we're rewriting history, it might be good idea to change directory structure to be more alike to the structure that other components have. The additional downside here is that the historical versions will not be fully functional - specifically it will break references from examples and tests to the rest of Boost.Build. But, I think it's worth the trouble - users can still obtain old, fully functional, versions from the tags, or master branch (yet another reason for it not to be rewritten), while developers will enjoy both clean directory structure and fully functional history on 'develop' branch.
So, the way I'd most like Boost.Build develop branch to look is this:
https://github.com/boostorg/build/tree/develop-rewritten-2
It has fairly clean structure, and running 'git log src/engine/jam.c' goes all the way to initial jam code import. The original post-conversion state is stored at converted-develop tag.
Steven, Jurgen, what do you think? Any other concerns I have overlooked. I really would like to to get over git games, and declare the repository to be ready, so unless I'll hear objections by the end of Monday, I will force-push this to develop branch and adjust the super-project as necessary.
I am gonna switch 'develop' to this version tomorrow morning, Moscow time.
It is done: https://github.com/boostorg/build/tree/develop Between I've started playing with rewrite and today, Juergen merged a few pull requests. I've created a tag to point at develop branch state right before I've force-pushed my changes, which is prerewrite-develop, and I believe all of the commits are now on the rewritten branch. Then, I've merged to master in a way that makes master's tip tree be equal to develop's tip tree, while still recording current tips of master and develop as parents, as follows: $ echo "Merge develop" | git commit-tree cb54f66965b5b8571cd1ab28939666034552072d -p 87098597c066240567d3b5556e0689a7c9d5720f -p dc428e2ab3bf198ebc8a53b5b25d09fa7b29e4a1 8c178d6bdbe352b487e9cdb88fd9773a708637ea $ git reset --hard 8c178d6bdbe352b487e9cdb88fd9773a708637ea $ git commit --amend (edit log message to be more useful) The whole point of this exercise was to avoid more forces pushes. Also, it makes further merges from develop to master just work. It does make master history a bit more messy, but it's not it's useful for anything anyway. Now, if you've got clones of build repository, some work is required. - If you have local clone with no changes on 'develop' branch, do: git fetch git checkout develop git reset --hard origin/develop - If you have local clone with some changes on 'develop' branch, do: git fetch git branch develop-old develop git checkout develop git reset --hard origin/develop git log develop-old # for every local change, do git cherry-pick <commit-id> - If you have local clone of a github clone, do this: git remote add boostorg git@github.com:boostorg/build.git and then do everything as above, replacing origin with boostorg. At the end, do 'git push -f' If anybody has any issues, drop me a line or talk to me on IRC and I'll help. Thanks, Volodya
On 12/18/2013 2:10 AM, Vladimir Prus wrote:
On 17.12.2013 22:33, Vladimir Prus wrote:
On 14.12.2013 21:44, Vladimir Prus wrote:
I've spent some time looking at history of Boost.Build git repository, and I think I've got a fairly reasonable outcome.
The problem statement is that in the converted repository, the top-level has nothing but a directory called 'v2', which is rather ugly. While it can be fixed with 'git mv', it would mean that 'git log file' will not show complete history unless the --follow option is passed, which is inconvenient. It appears that graphical tools don't like moves much either. There were already moves in SVN, so even now, running 'git log' on any file in engine/ won't return complete history without --follow. Further, at some older revision, there are two copies of what was jam code then.
The most convenient solution for these problems is to edit history of the 'develop' branch, so that content of top-level directory matches what was in 'v2' in SVN, and so that content of 'engine' matches Jam sources through the years. This won't actually break any important references from the super-project, first because they presumably are only to master branch, and second, because the commit objects will be still retained in repository. I am not sure we need to rewrite the 'master' branch, as it's not used for day to day development.
Now, as soon as we're rewriting history, it might be good idea to change directory structure to be more alike to the structure that other components have. The additional downside here is that the historical versions will not be fully functional - specifically it will break references from examples and tests to the rest of Boost.Build. But, I think it's worth the trouble - users can still obtain old, fully functional, versions from the tags, or master branch (yet another reason for it not to be rewritten), while developers will enjoy both clean directory structure and fully functional history on 'develop' branch.
So, the way I'd most like Boost.Build develop branch to look is this:
https://github.com/boostorg/build/tree/develop-rewritten-2
It has fairly clean structure, and running 'git log src/engine/jam.c' goes all the way to initial jam code import. The original post-conversion state is stored at converted-develop tag.
Steven, Jurgen, what do you think? Any other concerns I have overlooked. I really would like to to get over git games, and declare the repository to be ready, so unless I'll hear objections by the end of Monday, I will force-push this to develop branch and adjust the super-project as necessary.
I am gonna switch 'develop' to this version tomorrow morning, Moscow time.
It is done:
https://github.com/boostorg/build/tree/develop
Between I've started playing with rewrite and today, Juergen merged a few pull requests. I've created a tag to point at develop branch state right before I've force-pushed my changes, which is prerewrite-develop, and I believe all of the commits are now on the rewritten branch.
Then, I've merged to master in a way that makes master's tip tree be equal to develop's tip tree, while still recording current tips of master and develop as parents, as follows:
$ echo "Merge develop" | git commit-tree cb54f66965b5b8571cd1ab28939666034552072d -p 87098597c066240567d3b5556e0689a7c9d5720f -p dc428e2ab3bf198ebc8a53b5b25d09fa7b29e4a1 8c178d6bdbe352b487e9cdb88fd9773a708637ea $ git reset --hard 8c178d6bdbe352b487e9cdb88fd9773a708637ea $ git commit --amend (edit log message to be more useful)
The whole point of this exercise was to avoid more forces pushes. Also, it makes further merges from develop to master just work. It does make master history a bit more messy, but it's not it's useful for anything anyway.
Now, if you've got clones of build repository, some work is required.
- If you have local clone with no changes on 'develop' branch, do:
git fetch git checkout develop git reset --hard origin/develop
- If you have local clone with some changes on 'develop' branch, do:
git fetch git branch develop-old develop git checkout develop git reset --hard origin/develop git log develop-old # for every local change, do git cherry-pick <commit-id>
- If you have local clone of a github clone, do this:
git remote add boostorg git@github.com:boostorg/build.git
and then do everything as above, replacing origin with boostorg. At the end, do 'git push -f'
If anybody has any issues, drop me a line or talk to me on IRC and I'll help.
Are you talking about just getting the latest changes to Boost Build submodule from its develop branch ?
On 18.12.2013 20:56, Edward Diener wrote:
On 12/18/2013 2:10 AM, Vladimir Prus wrote:
On 17.12.2013 22:33, Vladimir Prus wrote:
On 14.12.2013 21:44, Vladimir Prus wrote:
I've spent some time looking at history of Boost.Build git repository, and I think I've got a fairly reasonable outcome.
The problem statement is that in the converted repository, the top-level has nothing but a directory called 'v2', which is rather ugly. While it can be fixed with 'git mv', it would mean that 'git log file' will not show complete history unless the --follow option is passed, which is inconvenient. It appears that graphical tools don't like moves much either. There were already moves in SVN, so even now, running 'git log' on any file in engine/ won't return complete history without --follow. Further, at some older revision, there are two copies of what was jam code then.
The most convenient solution for these problems is to edit history of the 'develop' branch, so that content of top-level directory matches what was in 'v2' in SVN, and so that content of 'engine' matches Jam sources through the years. This won't actually break any important references from the super-project, first because they presumably are only to master branch, and second, because the commit objects will be still retained in repository. I am not sure we need to rewrite the 'master' branch, as it's not used for day to day development.
Now, as soon as we're rewriting history, it might be good idea to change directory structure to be more alike to the structure that other components have. The additional downside here is that the historical versions will not be fully functional - specifically it will break references from examples and tests to the rest of Boost.Build. But, I think it's worth the trouble - users can still obtain old, fully functional, versions from the tags, or master branch (yet another reason for it not to be rewritten), while developers will enjoy both clean directory structure and fully functional history on 'develop' branch.
So, the way I'd most like Boost.Build develop branch to look is this:
https://github.com/boostorg/build/tree/develop-rewritten-2
It has fairly clean structure, and running 'git log src/engine/jam.c' goes all the way to initial jam code import. The original post-conversion state is stored at converted-develop tag.
Steven, Jurgen, what do you think? Any other concerns I have overlooked. I really would like to to get over git games, and declare the repository to be ready, so unless I'll hear objections by the end of Monday, I will force-push this to develop branch and adjust the super-project as necessary.
I am gonna switch 'develop' to this version tomorrow morning, Moscow time.
It is done:
https://github.com/boostorg/build/tree/develop
Between I've started playing with rewrite and today, Juergen merged a few pull requests. I've created a tag to point at develop branch state right before I've force-pushed my changes, which is prerewrite-develop, and I believe all of the commits are now on the rewritten branch.
Then, I've merged to master in a way that makes master's tip tree be equal to develop's tip tree, while still recording current tips of master and develop as parents, as follows:
$ echo "Merge develop" | git commit-tree cb54f66965b5b8571cd1ab28939666034552072d -p 87098597c066240567d3b5556e0689a7c9d5720f -p dc428e2ab3bf198ebc8a53b5b25d09fa7b29e4a1 8c178d6bdbe352b487e9cdb88fd9773a708637ea $ git reset --hard 8c178d6bdbe352b487e9cdb88fd9773a708637ea $ git commit --amend (edit log message to be more useful)
The whole point of this exercise was to avoid more forces pushes. Also, it makes further merges from develop to master just work. It does make master history a bit more messy, but it's not it's useful for anything anyway.
Now, if you've got clones of build repository, some work is required.
- If you have local clone with no changes on 'develop' branch, do:
git fetch git checkout develop git reset --hard origin/develop
- If you have local clone with some changes on 'develop' branch, do:
git fetch git branch develop-old develop git checkout develop git reset --hard origin/develop git log develop-old # for every local change, do git cherry-pick <commit-id>
- If you have local clone of a github clone, do this:
git remote add boostorg git@github.com:boostorg/build.git
and then do everything as above, replacing origin with boostorg. At the end, do 'git push -f'
If anybody has any issues, drop me a line or talk to me on IRC and I'll help.
Are you talking about just getting the latest changes to Boost Build submodule from its develop branch ?
Yes. If you try to update an existing clone, you will likely get an error today. - Volodya
participants (3)
-
Edward Diener -
Michael Caisse -
Vladimir Prus