[git] The any library does not pull cleanly because of a forced update on develop and master.
I tried to update my local repositories to the latest changes in each
submodule:
git pull; git submodule foreach --recursive git pull
When it got to the libs/any submodule, I got the following message:
remote: Counting objects: 27, done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 6 (delta 2), reused 6 (delta 2)
Unpacking objects: 100% (6/6), done.
>From https://github.com/boostorg/any
+ 3f0b981...e3e5da6 develop -> origin/develop (forced update)
+ 38039b3...d35b2d6 master -> origin/master (forced update)
* [new tag] 20131209-develop -> 20131209-develop
* [new tag] 20131209-master -> 20131209-master
and my editor popped up with a merge commit message to edit. I think
that's because the develop and master branches were force updated,
re-writing history in develop and master.
Michael
2013/12/10 Cox, Michael <mhcox@bluezoosoftware.com>
I tried to update my local repositories to the latest changes in each submodule:
git pull; git submodule foreach --recursive git pull
When it got to the libs/any submodule, I got the following message:
You'll be getting the same messages during pull of conversion, variant, circular_buffer libraries. *If there is no changes in your local repo that must be saved*, you can try the following: http://stackoverflow.com/questions/1125968/force-git-to-overwrite-local-file... As I understand, command to do so for all submodules will be (!removes all local changes!): git submodule foreach --recursive 'git checkout develop && git fetch --all && git reset --hard origin/develop && git checkout master && git fetch --all && git reset --hard origin/master' Sorry for the inconvenience caused. -- Best regards, Antony Polukhin
Date: Tue, 10 Dec 2013 11:37:37 +0400 From: antoshkka@gmail.com To: boost@lists.boost.org Subject: Re: [boost] [git] The any library does not pull cleanly because of a forced update on develop and master.
2013/12/10 Cox, Michael <mhcox@bluezoosoftware.com>
I tried to update my local repositories to the latest changes in each submodule:
git pull; git submodule foreach --recursive git pull
When it got to the libs/any submodule, I got the following message:
You'll be getting the same messages during pull of conversion, variant, circular_buffer libraries. *If there is no changes in your local repo that must be saved*, you can try the following: http://stackoverflow.com/questions/1125968/force-git-to-overwrite-local-file...
As I understand, command to do so for all submodules will be (!removes all local changes!):
git submodule foreach --recursive 'git checkout develop && git fetch --all && git reset --hard origin/develop && git checkout master && git fetch --all && git reset --hard origin/master'
Sorry for the inconvenience caused.
Just curious, what was the motivation for the non-fast-forward push?
2013/12/10 Ahmed Charles <acharles@outlook.com>
Date: Tue, 10 Dec 2013 11:37:37 +0400 From: antoshkka@gmail.com To: boost@lists.boost.org Subject: Re: [boost] [git] The any library does not pull cleanly because of a forced update on develop and master.
2013/12/10 Cox, Michael <mhcox@bluezoosoftware.com>
I tried to update my local repositories to the latest changes in each submodule:
git pull; git submodule foreach --recursive git pull
When it got to the libs/any submodule, I got the following message:
You'll be getting the same messages during pull of conversion, variant, circular_buffer libraries. *If there is no changes in your local repo that must be saved*, you can try the following:
http://stackoverflow.com/questions/1125968/force-git-to-overwrite-local-file...
As I understand, command to do so for all submodules will be (!removes
all
local changes!):
git submodule foreach --recursive 'git checkout develop && git fetch --all && git reset --hard origin/develop && git checkout master && git fetch --all && git reset --hard origin/master'
Sorry for the inconvenience caused.
Just curious, what was the motivation for the non-fast-forward push?
Was unmerging old svn branches from develop branch and hiding them under branches/refs/hidden, like it was advised in "[boost] [git] Mess with branches" -- Best regards, Antony Polukhin
Antony Polukhin <antoshkka@gmail.com> writes:
2013/12/10 Ahmed Charles <acharles@outlook.com>
Date: Tue, 10 Dec 2013 11:37:37 +0400 From: antoshkka@gmail.com To: boost@lists.boost.org Subject: Re: [boost] [git] The any library does not pull cleanly because of a forced update on develop and master.
2013/12/10 Cox, Michael <mhcox@bluezoosoftware.com>
I tried to update my local repositories to the latest changes in each submodule:
git pull; git submodule foreach --recursive git pull
When it got to the libs/any submodule, I got the following message:
You'll be getting the same messages during pull of conversion, variant, circular_buffer libraries. *If there is no changes in your local repo that must be saved*, you can try the following:
http://stackoverflow.com/questions/1125968/force-git-to-overwrite-local-file...
As I understand, command to do so for all submodules will be (!removes
all
local changes!):
git submodule foreach --recursive 'git checkout develop && git fetch --all && git reset --hard origin/develop && git checkout master && git fetch --all && git reset --hard origin/master'
Sorry for the inconvenience caused.
Just curious, what was the motivation for the non-fast-forward push?
Was unmerging old svn branches from develop branch and hiding them under branches/refs/hidden, like it was advised in "[boost] [git] Mess with branches"
Un-merging?! That's alarming.
Date: Tue, 10 Dec 2013 12:11:25 +0400 From: antoshkka@gmail.com To: boost@lists.boost.org Subject: Re: [boost] [git] The any library does not pull cleanly because of a forced update on develop and master.
Was unmerging old svn branches from develop branch and hiding them under branches/refs/hidden, like it was advised in "[boost] [git] Mess with branches"
I believe I read that thread and it didn't mention changing history that I noticed. Deleting branches is 'git branch -D' and hiding a branch is 'git push origin <branch>:refs/hidden/<branch>', neither of which change history.
On 11 December 2013 04:45, Ahmed Charles <acharles@outlook.com> wrote:
Date: Tue, 10 Dec 2013 12:11:25 +0400 From: antoshkka@gmail.com To: boost@lists.boost.org Subject: Re: [boost] [git] The any library does not pull cleanly because of a forced update on develop and master.
Was unmerging old svn branches from develop branch and hiding them under branches/refs/hidden, like it was advised in "[boost] [git] Mess with branches"
I believe I read that thread and it didn't mention changing history that I noticed. Deleting branches is 'git branch -D' and hiding a branch is 'git push origin <branch>:refs/hidden/<branch>', neither of which change history.
He reverted in order to remove the massive merge of a lot of branches into develop. The history that those merges created was confusing, so it might have been a good idea. Hiding the branches caused problems though: http://lists.boost.org/Archives/boost/2013/12/209501.php I tagged the hidden branches to fix that. The rule should be: never hide anything that has been included in the super-project. Hiding the branches wouldn't have been a problem if the merge hadn't been included in the super project, but since it has been they needed to be tagged.
"Cox, Michael" <mhcox@bluezoosoftware.com> writes:
I tried to update my local repositories to the latest changes in each submodule:
git pull; git submodule foreach --recursive git pull
When it got to the libs/any submodule, I got the following message:
remote: Counting objects: 27, done. remote: Compressing objects: 100% (2/2), done. remote: Total 6 (delta 2), reused 6 (delta 2) Unpacking objects: 100% (6/6), done. From https://github.com/boostorg/any + 3f0b981...e3e5da6 develop -> origin/develop (forced update) + 38039b3...d35b2d6 master -> origin/master (forced update) * [new tag] 20131209-develop -> 20131209-develop * [new tag] 20131209-master -> 20131209-master
and my editor popped up with a merge commit message to edit. I think that's because the develop and master branches were force updated, re-writing history in develop and master.
If there is not already a policy in place to prevent history rewriting in public branches, we should have one. And if there's a GitHub mechanism for denying the privilege, it should be enabled. -Dave
On 10.12.2013 18:40, Dave Abrahams wrote:
"Cox, Michael" <mhcox@bluezoosoftware.com> writes:
I tried to update my local repositories to the latest changes in each submodule:
git pull; git submodule foreach --recursive git pull
When it got to the libs/any submodule, I got the following message:
remote: Counting objects: 27, done. remote: Compressing objects: 100% (2/2), done. remote: Total 6 (delta 2), reused 6 (delta 2) Unpacking objects: 100% (6/6), done. From https://github.com/boostorg/any + 3f0b981...e3e5da6 develop -> origin/develop (forced update) + 38039b3...d35b2d6 master -> origin/master (forced update) * [new tag] 20131209-develop -> 20131209-develop * [new tag] 20131209-master -> 20131209-master
and my editor popped up with a merge commit message to edit. I think that's because the develop and master branches were force updated, re-writing history in develop and master.
If there is not already a policy in place to prevent history rewriting in public branches, we should have one. And if there's a GitHub mechanism for denying the privilege, it should be enabled.
As I've said on Boost.Build mailing list, such a policy or mechanism shall only be in effect after everybody reviews results of the conversion for real, and is happy with them. The conversion was, to a degree, rushed, so we need a time to fix issues before we declare we're really done with the transition to git and start playing by git rules. - Volodya
On 10 December 2013 15:45, Vladimir Prus <ghost@cs.msu.su> wrote:
On 10.12.2013 18:40, Dave Abrahams wrote:
If there is not already a policy in place to prevent history rewriting in public branches, we should have one. And if there's a GitHub mechanism for denying the privilege, it should be enabled.
As I've said on Boost.Build mailing list, such a policy or mechanism shall only be in effect after everybody reviews results of the conversion for real, and is happy with them. The conversion was, to a degree, rushed, so we need a time to fix issues before we declare we're really done with the transition to git and start playing by git rules.
I think we also need to point predef and odeint's master and develop branches at completely different branches in order to import their git repositories. I don't think they should be required to merge in the history converted from subversion.
On 10/12/13 16:45, Vladimir Prus wrote:
As I've said on Boost.Build mailing list, such a policy or mechanism shall only be in effect after everybody reviews results of the conversion for real, and is happy with them. The conversion was, to a degree, rushed, so we need a time to fix issues before we declare we're really done with the transition to git and start playing by git rules.
Isn't that period over according to the planning? There was a period for library authors to review the history migrated to git.
On 10.12.2013 20:36, Mathias Gaunard wrote:
On 10/12/13 16:45, Vladimir Prus wrote:
As I've said on Boost.Build mailing list, such a policy or mechanism shall only be in effect after everybody reviews results of the conversion for real, and is happy with them. The conversion was, to a degree, rushed, so we need a time to fix issues before we declare we're really done with the transition to git and start playing by git rules.
Isn't that period over according to the planning? There was a period for library authors to review the history migrated to git.
FWIW, during that period, I did express a preference for 'build' repository to have everything at top level, as opposed to 'v2' subdir. - Volodya
On 12/10/2013 11:42 AM, Vladimir Prus wrote:
On 10.12.2013 20:36, Mathias Gaunard wrote:
On 10/12/13 16:45, Vladimir Prus wrote:
As I've said on Boost.Build mailing list, such a policy or mechanism shall only be in effect after everybody reviews results of the conversion for real, and is happy with them. The conversion was, to a degree, rushed, so we need a time to fix issues before we declare we're really done with the transition to git and start playing by git rules.
Isn't that period over according to the planning? There was a period for library authors to review the history migrated to git.
FWIW, during that period, I did express a preference for 'build' repository to have everything at top level, as opposed to 'v2' subdir.
Why can't you move it to the top level rather than have it at 'v2', then commit the changes and push to develop ? Do you mean that your history is lost in git for a file if you move it to another place in the repository ? Being a git novice that's hard to believe.
On 11.12.2013 00:04, Edward Diener wrote:
On 12/10/2013 11:42 AM, Vladimir Prus wrote:
On 10.12.2013 20:36, Mathias Gaunard wrote:
On 10/12/13 16:45, Vladimir Prus wrote:
As I've said on Boost.Build mailing list, such a policy or mechanism shall only be in effect after everybody reviews results of the conversion for real, and is happy with them. The conversion was, to a degree, rushed, so we need a time to fix issues before we declare we're really done with the transition to git and start playing by git rules.
Isn't that period over according to the planning? There was a period for library authors to review the history migrated to git.
FWIW, during that period, I did express a preference for 'build' repository to have everything at top level, as opposed to 'v2' subdir.
Why can't you move it to the top level rather than have it at 'v2', then commit the changes and push to develop ? Do you mean that your history is lost in git for a file if you move it to another place in the repository ? Being a git novice that's hard to believe.
After this change, git log file will output a single commit. You can kinda fix this by passing --follow, but you need to do this every time, there's no documented way to have it as default. Further, gitk does not appear to handle this at all, it just shows a single revision (e.g. if run like 'gitk build/virtual-target.jam'). Then, printing past becomes inconvenient: $ git show 5a0d9820ac6bd4068a1fa3075d45904ed5341675:build/virtual-target.jam fatal: Path 'build/virtual-target.jam' exists on disk, but not in '5a0d9820ac6bd4068a1fa3075d45904ed5341675' It is possible to use v2/build/virtual-target.jam in this case, but it's becoming not funny. And, importantly, given that a few people said that rename should "just work", which is demonstrably false, I suspect that there are further gotchas beyond the above immediate ones. - Volodya
On 12/10/2013 4:01 PM, Vladimir Prus wrote:
On 11.12.2013 00:04, Edward Diener wrote:
On 12/10/2013 11:42 AM, Vladimir Prus wrote:
On 10.12.2013 20:36, Mathias Gaunard wrote:
On 10/12/13 16:45, Vladimir Prus wrote:
As I've said on Boost.Build mailing list, such a policy or mechanism shall only be in effect after everybody reviews results of the conversion for real, and is happy with them. The conversion was, to a degree, rushed, so we need a time to fix issues before we declare we're really done with the transition to git and start playing by git rules.
Isn't that period over according to the planning? There was a period for library authors to review the history migrated to git.
FWIW, during that period, I did express a preference for 'build' repository to have everything at top level, as opposed to 'v2' subdir.
Why can't you move it to the top level rather than have it at 'v2', then commit the changes and push to develop ? Do you mean that your history is lost in git for a file if you move it to another place in the repository ? Being a git novice that's hard to believe.
After this change,
git log file
will output a single commit. You can kinda fix this by passing --follow, but you need to do this every time, there's no documented way to have it as default. Further, gitk does not appear to handle this at all, it just shows a single revision (e.g. if run like 'gitk build/virtual-target.jam').
Then, printing past becomes inconvenient:
$ git show 5a0d9820ac6bd4068a1fa3075d45904ed5341675:build/virtual-target.jam fatal: Path 'build/virtual-target.jam' exists on disk, but not in '5a0d9820ac6bd4068a1fa3075d45904ed5341675'
It is possible to use v2/build/virtual-target.jam in this case, but it's becoming not funny. And, importantly, given that a few people said that rename should "just work", which is demonstrably false, I suspect that there are further gotchas beyond the above immediate ones.
I admit to being a git novice but I am truly shocked that moving a file to another place in a repository through some git command does not keep all of the previous history. Maybe someone who knows git can explain why this is so but it sure seems to me to be a totally erroneous way of treating a move.
On 11/12/2013 13:01, Quoth Edward Diener:
On 12/10/2013 4:01 PM, Vladimir Prus wrote:
On 11.12.2013 00:04, Edward Diener wrote:
On 12/10/2013 11:42 AM, Vladimir Prus wrote:
On 10.12.2013 20:36, Mathias Gaunard wrote:
On 10/12/13 16:45, Vladimir Prus wrote:
As I've said on Boost.Build mailing list, such a policy or mechanism shall only be in effect after everybody reviews results of the conversion for real, and is happy with them. The conversion was, to a degree, rushed, so we need a time to fix issues before we declare we're really done with the transition to git and start playing by git rules.
Isn't that period over according to the planning? There was a period for library authors to review the history migrated to git.
FWIW, during that period, I did express a preference for 'build' repository to have everything at top level, as opposed to 'v2' subdir.
Why can't you move it to the top level rather than have it at 'v2', then commit the changes and push to develop ? Do you mean that your history is lost in git for a file if you move it to another place in the repository ? Being a git novice that's hard to believe.
After this change,
git log file
will output a single commit. You can kinda fix this by passing --follow, but you need to do this every time, there's no documented way to have it as default. Further, gitk does not appear to handle this at all, it just shows a single revision (e.g. if run like 'gitk build/virtual-target.jam').
Then, printing past becomes inconvenient:
$ git show 5a0d9820ac6bd4068a1fa3075d45904ed5341675:build/virtual-target.jam fatal: Path 'build/virtual-target.jam' exists on disk, but not in '5a0d9820ac6bd4068a1fa3075d45904ed5341675'
It is possible to use v2/build/virtual-target.jam in this case, but it's becoming not funny. And, importantly, given that a few people said that rename should "just work", which is demonstrably false, I suspect that there are further gotchas beyond the above immediate ones.
I admit to being a git novice but I am truly shocked that moving a file to another place in a repository through some git command does not keep all of the previous history. Maybe someone who knows git can explain why this is so but it sure seems to me to be a totally erroneous way of treating a move.
AFAICT from discussion above, Git behaves the same as SVN, except that SVN defaults to following moves (and --stop-on-copy disables that) and Git defaults to not following moves (and --follow enables that). It's just as painful in SVN to view the contents of a past file through a copy/move/delete, until you get experienced with peg revisions or you use an interactive repository browser to view the whole tree as it appeared in the past. (And, once you know a commit hash prior to the move, you can use "gitk 5a0d9820ac6bd4068a1fa3075d45904ed5341675" to view that revision and its history, just like you can with SVN.)
On 12/10/2013 7:32 PM, Gavin Lambert wrote:
On 11/12/2013 13:01, Quoth Edward Diener:
On 12/10/2013 4:01 PM, Vladimir Prus wrote:
On 11.12.2013 00:04, Edward Diener wrote:
On 12/10/2013 11:42 AM, Vladimir Prus wrote:
On 10.12.2013 20:36, Mathias Gaunard wrote:
On 10/12/13 16:45, Vladimir Prus wrote:
> As I've said on Boost.Build mailing list, such a policy or mechanism > shall only be in effect after > everybody reviews results of the conversion for real, and is happy > with > them. The conversion was, > to a degree, rushed, so we need a time to fix issues before we > declare > we're really done with > the transition to git and start playing by git rules.
Isn't that period over according to the planning? There was a period for library authors to review the history migrated to git.
FWIW, during that period, I did express a preference for 'build' repository to have everything at top level, as opposed to 'v2' subdir.
Why can't you move it to the top level rather than have it at 'v2', then commit the changes and push to develop ? Do you mean that your history is lost in git for a file if you move it to another place in the repository ? Being a git novice that's hard to believe.
After this change,
git log file
will output a single commit. You can kinda fix this by passing --follow, but you need to do this every time, there's no documented way to have it as default. Further, gitk does not appear to handle this at all, it just shows a single revision (e.g. if run like 'gitk build/virtual-target.jam').
Then, printing past becomes inconvenient:
$ git show 5a0d9820ac6bd4068a1fa3075d45904ed5341675:build/virtual-target.jam fatal: Path 'build/virtual-target.jam' exists on disk, but not in '5a0d9820ac6bd4068a1fa3075d45904ed5341675'
It is possible to use v2/build/virtual-target.jam in this case, but it's becoming not funny. And, importantly, given that a few people said that rename should "just work", which is demonstrably false, I suspect that there are further gotchas beyond the above immediate ones.
I admit to being a git novice but I am truly shocked that moving a file to another place in a repository through some git command does not keep all of the previous history. Maybe someone who knows git can explain why this is so but it sure seems to me to be a totally erroneous way of treating a move.
AFAICT from discussion above, Git behaves the same as SVN, except that SVN defaults to following moves (and --stop-on-copy disables that) and Git defaults to not following moves (and --follow enables that).
It sounded like in git one must continuously specify --follow after the move with each commit in order to preserve history, or was the person who said that mistaken ? Intuitively to me once one uses a command to tell git that a file in a repository is being moved/renamed to something else in the repository and that the previous history should follow that file, then one should always be able to see the full history of that file both before ane after the move/rename.
It's just as painful in SVN to view the contents of a past file through a copy/move/delete, until you get experienced with peg revisions or you use an interactive repository browser to view the whole tree as it appeared in the past.
(And, once you know a commit hash prior to the move, you can use "gitk 5a0d9820ac6bd4068a1fa3075d45904ed5341675" to view that revision and its history, just like you can with SVN.)
I do not think that one should ever have to know some abstruse commit number in order to see the history of a file in a repository.
To: boost@lists.boost.org From: eldiener@tropicsoft.com Date: Tue, 10 Dec 2013 22:19:30 -0500 Subject: Re: [boost] [git] The any library does not pull cleanly because of a forced update on develop and master.
It sounded like in git one must continuously specify --follow after the move with each commit in order to preserve history, or was the person who said that mistaken ?
Intuitively to me once one uses a command to tell git that a file in a repository is being moved/renamed to something else in the repository and that the previous history should follow that file, then one should always be able to see the full history of that file both before ane after the move/rename.
It's just as painful in SVN to view the contents of a past file through a copy/move/delete, until you get experienced with peg revisions or you use an interactive repository browser to view the whole tree as it appeared in the past.
(And, once you know a commit hash prior to the move, you can use "gitk 5a0d9820ac6bd4068a1fa3075d45904ed5341675" to view that revision and its history, just like you can with SVN.)
I do not think that one should ever have to know some abstruse commit number in order to see the history of a file in a repository.
There seems to be some amount of misinformation/confusion in this thread, so here's an example: == Create the repository. ~ $ mkdir file ~ $ cd file/ ~/file $ git init Initialized empty Git repository in ~/file/.git/ ~/file (master #) $ git status # On branch master # # Initial commit # nothing to commit (create/copy files and use "git add" to track) == Add a file and make a series of commits with changes to it. ~/file (master #) $ echo "line 1" >> file.txt ~/file (master #%) $ git add file.txt ~/file (master #) $ git ci -m "line 1" [master (root-commit) d29d848] line 1 1 file changed, 1 insertion(+) create mode 100644 file.txt ~/file (master) $ echo "line 2" >> file.txt ~/file (master *) $ git ci -a -m "line 2" [master 7c0ee29] line 2 1 file changed, 1 insertion(+) ~/file (master) $ echo "line 3" >> file.txt ~/file (master *) $ git ci -a -m "line 3" [master c7b1f4c] line 3 1 file changed, 1 insertion(+) == Move the file to a new name. ~/file (master) $ git mv file.txt other.txt ~/file (master +) $ git st # On branch master # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # renamed: file.txt -> other.txt # ~/file (master +) $ git ci -m "move file.txt to other.txt" [master 5e581f3] move file.txt to other.txt 1 file changed, 0 insertions(+), 0 deletions(-) rename file.txt => other.txt (100%) == Add another change to the file under it's new name. ~/file (master) $ echo "line 4" >> other.txt ~/file (master *) $ git ci -a -m "line 4" [master c4a8b48] line 4 1 file changed, 1 insertion(+) == Run git log, which shows all of the commits. ~/file (master) $ git log commit c4a8b48fbf38a9b06376b30a36a76b6a674384a9 Author: Ahmed Charles <ahmedcharles@gmail.com> Date: Tue Dec 10 20:19:41 2013 -0800 line 4 commit 5e581f3b61a759b8e572e7fe4f1a2081bcb7aed8 Author: Ahmed Charles <ahmedcharles@gmail.com> Date: Tue Dec 10 20:19:19 2013 -0800 move file.txt to other.txt commit c7b1f4ce30b199794e29a151642267d84842d03b Author: Ahmed Charles <ahmedcharles@gmail.com> Date: Tue Dec 10 20:18:31 2013 -0800 line 3 commit 7c0ee297b1f76c73badbc07b5bf426f5cb521e35 Author: Ahmed Charles <ahmedcharles@gmail.com> Date: Tue Dec 10 20:17:54 2013 -0800 line 2 commit d29d848569c0d620e45d6e18d10650da1c0cf1d4 Author: Ahmed Charles <ahmedcharles@gmail.com> Date: Tue Dec 10 20:17:25 2013 -0800 line 1 == Run git log <file>, which shows commits to that file, note, it only shows the last two. ~/file (master) $ git log other.txt commit c4a8b48fbf38a9b06376b30a36a76b6a674384a9 Author: Ahmed Charles <ahmedcharles@gmail.com> Date: Tue Dec 10 20:19:41 2013 -0800 line 4 commit 5e581f3b61a759b8e572e7fe4f1a2081bcb7aed8 Author: Ahmed Charles <ahmedcharles@gmail.com> Date: Tue Dec 10 20:19:19 2013 -0800 move file.txt to other.txt == Run git log --follow <file>, which shows commits to that file and follows the file through moves. ~/file (master) $ git log --follow other.txt commit c4a8b48fbf38a9b06376b30a36a76b6a674384a9 Author: Ahmed Charles <ahmedcharles@gmail.com> Date: Tue Dec 10 20:19:41 2013 -0800 line 4 commit 5e581f3b61a759b8e572e7fe4f1a2081bcb7aed8 Author: Ahmed Charles <ahmedcharles@gmail.com> Date: Tue Dec 10 20:19:19 2013 -0800 move file.txt to other.txt commit c7b1f4ce30b199794e29a151642267d84842d03b Author: Ahmed Charles <ahmedcharles@gmail.com> Date: Tue Dec 10 20:18:31 2013 -0800 line 3 commit 7c0ee297b1f76c73badbc07b5bf426f5cb521e35 Author: Ahmed Charles <ahmedcharles@gmail.com> Date: Tue Dec 10 20:17:54 2013 -0800 line 2 commit d29d848569c0d620e45d6e18d10650da1c0cf1d4 Author: Ahmed Charles <ahmedcharles@gmail.com> Date: Tue Dec 10 20:17:25 2013 -0800 line 1 So, to be accurate, the complaint is that '--follow' is required when running git log on a file which has been moved at some point in it's history. The point about gitk would simply be that you need to copy/paste a sha1 from the output of git log and using it, for example, 'gitk c7b1f4ce30b199794e29a151642267d84842d03b'. Note, I don't have gitk, so I haven't tested this part. I don't find either of these aspects of git to be a compelling reason to modify history, which is generally considered to be poor form in any git community and boost should be no different. Making everyone who is using boost through git deal with a non-fast-forward merge is too high a cost for simply getting to avoid typing 8 extra characters, especially when you can just do: git config --global alias.logf 'log --follow' And then whenever you do 'git logf file.txt' it will follow that file for you (and if you make the alias lf, it's less typing than before). I second the request to have boost policy changed to disallow modifying history without really good reasons to do so, where really good means that there is some form of consensus on the list before the change is made.
On 11.12.2013 08:42, Ahmed Charles wrote:
I don't find either of these aspects of git to be a compelling reason to modify history, which is generally considered to be poor form in any git community and boost should be no different. Making everyone who is using boost through git deal with a non-fast-forward merge is too high a cost for simply getting to avoid typing 8 extra characters
Dealing with non-fast-forward merge at this just-post-conversion point is trivial. There are not many forks, and presumably not many people who have non-trivial local changes. May I ask that this sub-thread don't become yet another where general git advice is given? Rather, if anybody knows specific reason why rewriting history of the 'build' module *now* will create problems for *him*, please speak up. Otherwise, I'll evaluate technical feasibility (our beloved git might as well take years to run filter-branch), and if it works, will proceed. - Volodya
To: boost@lists.boost.org From: ghost@cs.msu.su Date: Wed, 11 Dec 2013 08:54:03 +0400 Subject: Re: [boost] [git] The any library does not pull cleanly because of a forced update on develop and master.
On 11.12.2013 08:42, Ahmed Charles wrote:
I don't find either of these aspects of git to be a compelling reason to modify history, which is generally considered to be poor form in any git community and boost should be no different. Making everyone who is using boost through git deal with a non-fast-forward merge is too high a cost for simply getting to avoid typing 8 extra characters
Dealing with non-fast-forward merge at this just-post-conversion point is trivial. There are not many forks, and presumably not many people who have non-trivial local changes.
May I ask that this sub-thread don't become yet another where general git advice is given? Rather, if anybody knows specific reason why rewriting history of the 'build' module *now* will create problems for *him*, please speak up. Otherwise, I'll evaluate technical feasibility (our beloved git might as well take years to run filter-branch), and if it works, will proceed.
What's the motivation for this specific change vs the alternative which doesn't require changing the history?
On 11.12.2013 08:57, Ahmed Charles wrote:
To: boost@lists.boost.org From: ghost@cs.msu.su Date: Wed, 11 Dec 2013 08:54:03 +0400 Subject: Re: [boost] [git] The any library does not pull cleanly because of a forced update on develop and master.
On 11.12.2013 08:42, Ahmed Charles wrote:
I don't find either of these aspects of git to be a compelling reason to modify history, which is generally considered to be poor form in any git community and boost should be no different. Making everyone who is using boost through git deal with a non-fast-forward merge is too high a cost for simply getting to avoid typing 8 extra characters
Dealing with non-fast-forward merge at this just-post-conversion point is trivial. There are not many forks, and presumably not many people who have non-trivial local changes.
May I ask that this sub-thread don't become yet another where general git advice is given? Rather, if anybody knows specific reason why rewriting history of the 'build' module *now* will create problems for *him*, please speak up. Otherwise, I'll evaluate technical feasibility (our beloved git might as well take years to run filter-branch), and if it works, will proceed.
What's the motivation for this specific change vs the alternative which doesn't require changing the history?
Sorry, I've said it several times already, please check this thread and boost-build@lists.boost.org thread. This is my module, I want the history to be in a way that is convenient for me. If conversion failed to do this, I want to fix it myself. - Volodya
To: boost@lists.boost.org From: ghost@cs.msu.su Date: Wed, 11 Dec 2013 09:14:58 +0400 Subject: Re: [boost] [git] The any library does not pull cleanly because of a forced update on develop and master.
Sorry, I've said it several times already, please check this thread and boost-build@lists.boost.org thread. This is my module, I want the history to be in a way that is convenient for me. If conversion failed to do this, I want to fix it myself.
I don't follow boost-build. Though, I did get that you wanted it 'convenient for you', however, that's not detailed enough for anyone else to actually help you achieve it. I was asking for motivation in the hope of getting something more detailed. Unfortunately, as it stands, you seem willing to unilaterally and knowingly inconvenience everyone with a git clone of boost simply because you think it will improve things for you without even explaining what that means. I don't want this to sound too critical and certainly, boost always errs on the side of giving library developers control, but at the same time, something of this magnitude hasn't really been possible previously in boost, so there's no precedence for maintainers making changes like this. Note, this is equivalent to taking boosts svn server, making a copy with a different history and then changing the dns to point from the original to the new one. No one would have let you do that and the only reason you are even considering it is because git makes something like this as trivial as typing '-f'...
On 11.12.2013 09:25, Ahmed Charles wrote:
Unfortunately, as it stands, you seem willing to unilaterally and knowingly inconvenience everyone with a git clone of boost
I am not sure it's obvious, but git transition is not done. Anybody with a git clone of boost today shall expect much more entertainment than a need to 'git reset' a single module. And, BTW, technically I can rewrite the history without a single forced push. - Volodya
On Tue, Dec 10, 2013 at 10:35 PM, Vladimir Prus <ghost@cs.msu.su> wrote:
On 11.12.2013 09:25, Ahmed Charles wrote:
Unfortunately, as it stands, you seem willing to unilaterally and knowingly inconvenience everyone with a git clone of boost
I am not sure it's obvious, but git transition is not done. Anybody with a git clone of boost today shall expect much more entertainment than a need to 'git reset' a single module. And, BTW, technically I can rewrite the history without a single forced push.
How could rewriting the history be done without a forced push? Just so I can avoid accidentally doing that.
My understanding is that all git commits are cryptographically linked with the SHA numbers so that if you have a SHA number for a commit, you are guaranteed that commit and all the ones in its history are the same for you and any one else looking at them. Michael - Volodya
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/ mailman/listinfo.cgi/boost
On 11.12.2013 11:36, Cox, Michael wrote:
On Tue, Dec 10, 2013 at 10:35 PM, Vladimir Prus <ghost@cs.msu.su> wrote:
On 11.12.2013 09:25, Ahmed Charles wrote:
Unfortunately, as it stands, you seem willing to unilaterally and knowingly inconvenience everyone with a git clone of boost
I am not sure it's obvious, but git transition is not done. Anybody with a git clone of boost today shall expect much more entertainment than a need to 'git reset' a single module. And, BTW, technically I can rewrite the history without a single forced push.
How could rewriting the history be done without a forced push? Just so I can avoid accidentally doing that.
My understanding is that all git commits are cryptographically linked with the SHA numbers so that if you have a SHA number for a commit, you are guaranteed that commit and all the ones in its history are the same for you and any one else looking at them.
Just look at develop-rewritten branch in build repo - it is a history-rewritten version of 'develop', but no forced push is necessary - because it's another branch. - Volodya
On 11 December 2013 07:43, Vladimir Prus <ghost@cs.msu.su> wrote:
Just look at develop-rewritten branch in build repo - it is a history-rewritten version of 'develop', but no forced push is necessary - because it's another branch.
You're going to have to use a forced push to replace master and trunk.
On 11.12.2013 13:33, Daniel James wrote:
On 11 December 2013 07:43, Vladimir Prus <ghost@cs.msu.su> wrote:
Just look at develop-rewritten branch in build repo - it is a history-rewritten version of 'develop', but no forced push is necessary - because it's another branch.
You're going to have to use a forced push to replace master and trunk.
Did not we decide that 'develop' branch is not gonna be referenced by superproject at all (and the superproject/develop will link to module/master). In which case, I might not even want to use 'develop' branch name in the first place, so I won't bother to replace it. It all boils back to the point that we have quite a few things undecided at this point, so expecting that from now on, it will be possible to just update to new git state automatically is quite optimistic thinking. - Volodya
On 11 December 2013 09:44, Vladimir Prus <ghost@cs.msu.su> wrote:
On 11.12.2013 13:33, Daniel James wrote:
You're going to have to use a forced push to replace master and trunk.
s/trunk/develop/
Did not we decide that 'develop' branch is not gonna be referenced by superproject at all (and the superproject/develop will link to module/master).
No, we didn't. But you'll still have to force push to master at the very least.
To: boost@lists.boost.org From: ghost@cs.msu.su Date: Wed, 11 Dec 2013 13:44:01 +0400 Subject: Re: [boost] [git] The any library does not pull cleanly because of a forced update on develop and master.
It all boils back to the point that we have quite a few things undecided at this point, so expecting that from now on, it will be possible to just update to new git state automatically is quite optimistic thinking.
I'm not sure what you mean, but the assumption that a public branch (like master/develop in boost) is never force pushed, is fairly basic. It's not even possible to do in most other source control systems. Unfortunately, the flexibility of git results in mistakes and fixing them almost always has unfortunate tradeoffs and the best way to avoid mistakes is to take great care in the things one does.
On 11 December 2013 12:06, Ahmed Charles <acharles@outlook.com> wrote:
To: boost@lists.boost.org From: ghost@cs.msu.su Date: Wed, 11 Dec 2013 13:44:01 +0400 Subject: Re: [boost] [git] The any library does not pull cleanly because of a forced update on develop and master.
It all boils back to the point that we have quite a few things undecided at this point, so expecting that from now on, it will be possible to just update to new git state automatically is quite optimistic thinking.
I'm not sure what you mean, but the assumption that a public branch (like master/develop in boost) is never force pushed, is fairly basic. It's not even possible to do in most other source control systems. Unfortunately, the flexibility of git results in mistakes and fixing them almost always has unfortunate tradeoffs and the best way to avoid mistakes is to take great care in the things one does.
I think you can only make that assumption once we have settled into a stable state. We still haven't worked out how everything is going to fit together, and not all the parts are in place yet. There's a trade off between short term disruption and long term history, and at the moment the latter seems more important to me. We're still in the period of transition - we're not publicizing the git repositories for general use yet. If this is problematic for you, then you should probably wait before creating any branches. This is roughly an alpha phase for developers, where breaking changes can still happen.
On 11.12.2013 08:54, Vladimir Prus wrote:
On 11.12.2013 08:42, Ahmed Charles wrote:
I don't find either of these aspects of git to be a compelling reason to modify history, which is generally considered to be poor form in any git community and boost should be no different. Making everyone who is using boost through git deal with a non-fast-forward merge is too high a cost for simply getting to avoid typing 8 extra characters
Dealing with non-fast-forward merge at this just-post-conversion point is trivial. There are not many forks, and presumably not many people who have non-trivial local changes.
May I ask that this sub-thread don't become yet another where general git advice is given? Rather, if anybody knows specific reason why rewriting history of the 'build' module *now* will create problems for *him*, please speak up. Otherwise, I'll evaluate technical feasibility (our beloved git might as well take years to run filter-branch), and if it works, will proceed.
Okay, it works. The 'develop-rewritten' branch on github now has rewritten history with content of 'v2' at the top level. It goes accurately all the way to this: Author: Vladimir Prus <ghost@cs.msu.su> 2010-07-14 14:37:12 Committer: Vladimir Prus <ghost@cs.msu.su> 2010-07-14 14:37:12 Parent: f23e645d126a1a9038b687f339af62542b33a48e (Use toolset.requirements in targets.py) Child: 89479d87f20fd0f9f181f2bf1251f26a6665d405 (Stop 'import toolset in Jamfiles from reloading b2.build.tooset.) Branches: develop-rewritten, remotes/origin/develop-rewritten Follows: Precedes: Move tools/jam into tools/build/v2/engine [SVN r64010] Prior to that, history does not have sources of what was known as bjam - which does not seem like a problem for day to day development. In return, we have a proper history of Boost.Build V2 since the beginning of time. - Volodya
AMDG On 12/10/2013 09:28 PM, Vladimir Prus wrote:
<snip> Author: Vladimir Prus <ghost@cs.msu.su> 2010-07-14 14:37:12 Committer: Vladimir Prus <ghost@cs.msu.su> 2010-07-14 14:37:12 Parent: f23e645d126a1a9038b687f339af62542b33a48e (Use toolset.requirements in targets.py) Child: 89479d87f20fd0f9f181f2bf1251f26a6665d405 (Stop 'import toolset in Jamfiles from reloading b2.build.tooset.) Branches: develop-rewritten, remotes/origin/develop-rewritten Follows: Precedes:
Move tools/jam into tools/build/v2/engine
[SVN r64010]
Prior to that, history does not have sources of what was known as bjam - which does not seem like a problem for day to day development.
How do I get the older history, then?
In return, we have a proper history of Boost.Build V2 since the beginning of time.
In Christ, Steven Watanabe
On 11.12.2013 20:35, Steven Watanabe wrote:
AMDG
On 12/10/2013 09:28 PM, Vladimir Prus wrote:
<snip> Author: Vladimir Prus <ghost@cs.msu.su> 2010-07-14 14:37:12 Committer: Vladimir Prus <ghost@cs.msu.su> 2010-07-14 14:37:12 Parent: f23e645d126a1a9038b687f339af62542b33a48e (Use toolset.requirements in targets.py) Child: 89479d87f20fd0f9f181f2bf1251f26a6665d405 (Stop 'import toolset in Jamfiles from reloading b2.build.tooset.) Branches: develop-rewritten, remotes/origin/develop-rewritten Follows: Precedes:
Move tools/jam into tools/build/v2/engine
[SVN r64010]
Prior to that, history does not have sources of what was known as bjam - which does not seem like a problem for day to day development.
How do I get the older history, then?
There is already a tag 'converted-develop' which points to pristine results of conversions, and you can do 'git log converted-develop' to examine earlier history. Note that this will only be necessary if you want to examine engine commits made before 2010-07, not any of interpreted code changes - which are present all the way back. Will that work? - Volodya
On 12/10/2013 11:42 PM, Ahmed Charles wrote:
To: boost@lists.boost.org From: eldiener@tropicsoft.com Date: Tue, 10 Dec 2013 22:19:30 -0500 Subject: Re: [boost] [git] The any library does not pull cleanly because of a forced update on develop and master.
It sounded like in git one must continuously specify --follow after the move with each commit in order to preserve history, or was the person who said that mistaken ?
Intuitively to me once one uses a command to tell git that a file in a repository is being moved/renamed to something else in the repository and that the previous history should follow that file, then one should always be able to see the full history of that file both before ane after the move/rename.
It's just as painful in SVN to view the contents of a past file through a copy/move/delete, until you get experienced with peg revisions or you use an interactive repository browser to view the whole tree as it appeared in the past.
(And, once you know a commit hash prior to the move, you can use "gitk 5a0d9820ac6bd4068a1fa3075d45904ed5341675" to view that revision and its history, just like you can with SVN.)
I do not think that one should ever have to know some abstruse commit number in order to see the history of a file in a repository.
There seems to be some amount of misinformation/confusion in this thread, so here's an example:
== Create the repository. ~ $ mkdir file ~ $ cd file/ ~/file $ git init Initialized empty Git repository in ~/file/.git/ ~/file (master #) $ git status # On branch master # # Initial commit # nothing to commit (create/copy files and use "git add" to track)
== Add a file and make a series of commits with changes to it. ~/file (master #) $ echo "line 1" >> file.txt ~/file (master #%) $ git add file.txt ~/file (master #) $ git ci -m "line 1" [master (root-commit) d29d848] line 1 1 file changed, 1 insertion(+) create mode 100644 file.txt ~/file (master) $ echo "line 2" >> file.txt ~/file (master *) $ git ci -a -m "line 2" [master 7c0ee29] line 2 1 file changed, 1 insertion(+) ~/file (master) $ echo "line 3" >> file.txt ~/file (master *) $ git ci -a -m "line 3" [master c7b1f4c] line 3 1 file changed, 1 insertion(+)
== Move the file to a new name. ~/file (master) $ git mv file.txt other.txt ~/file (master +) $ git st # On branch master # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # renamed: file.txt -> other.txt # ~/file (master +) $ git ci -m "move file.txt to other.txt" [master 5e581f3] move file.txt to other.txt 1 file changed, 0 insertions(+), 0 deletions(-) rename file.txt => other.txt (100%)
== Add another change to the file under it's new name. ~/file (master) $ echo "line 4" >> other.txt ~/file (master *) $ git ci -a -m "line 4" [master c4a8b48] line 4 1 file changed, 1 insertion(+)
== Run git log, which shows all of the commits. ~/file (master) $ git log commit c4a8b48fbf38a9b06376b30a36a76b6a674384a9 Author: Ahmed Charles <ahmedcharles@gmail.com> Date: Tue Dec 10 20:19:41 2013 -0800
line 4
commit 5e581f3b61a759b8e572e7fe4f1a2081bcb7aed8 Author: Ahmed Charles <ahmedcharles@gmail.com> Date: Tue Dec 10 20:19:19 2013 -0800
move file.txt to other.txt
commit c7b1f4ce30b199794e29a151642267d84842d03b Author: Ahmed Charles <ahmedcharles@gmail.com> Date: Tue Dec 10 20:18:31 2013 -0800
line 3
commit 7c0ee297b1f76c73badbc07b5bf426f5cb521e35 Author: Ahmed Charles <ahmedcharles@gmail.com> Date: Tue Dec 10 20:17:54 2013 -0800
line 2
commit d29d848569c0d620e45d6e18d10650da1c0cf1d4 Author: Ahmed Charles <ahmedcharles@gmail.com> Date: Tue Dec 10 20:17:25 2013 -0800
line 1
== Run git log <file>, which shows commits to that file, note, it only shows the last two. ~/file (master) $ git log other.txt commit c4a8b48fbf38a9b06376b30a36a76b6a674384a9 Author: Ahmed Charles <ahmedcharles@gmail.com> Date: Tue Dec 10 20:19:41 2013 -0800
line 4
commit 5e581f3b61a759b8e572e7fe4f1a2081bcb7aed8 Author: Ahmed Charles <ahmedcharles@gmail.com> Date: Tue Dec 10 20:19:19 2013 -0800
move file.txt to other.txt
== Run git log --follow <file>, which shows commits to that file and follows the file through moves. ~/file (master) $ git log --follow other.txt commit c4a8b48fbf38a9b06376b30a36a76b6a674384a9 Author: Ahmed Charles <ahmedcharles@gmail.com> Date: Tue Dec 10 20:19:41 2013 -0800
line 4
commit 5e581f3b61a759b8e572e7fe4f1a2081bcb7aed8 Author: Ahmed Charles <ahmedcharles@gmail.com> Date: Tue Dec 10 20:19:19 2013 -0800
move file.txt to other.txt
commit c7b1f4ce30b199794e29a151642267d84842d03b Author: Ahmed Charles <ahmedcharles@gmail.com> Date: Tue Dec 10 20:18:31 2013 -0800
line 3
commit 7c0ee297b1f76c73badbc07b5bf426f5cb521e35 Author: Ahmed Charles <ahmedcharles@gmail.com> Date: Tue Dec 10 20:17:54 2013 -0800
line 2
commit d29d848569c0d620e45d6e18d10650da1c0cf1d4 Author: Ahmed Charles <ahmedcharles@gmail.com> Date: Tue Dec 10 20:17:25 2013 -0800
line 1
So, to be accurate, the complaint is that '--follow' is required when running git log on a file which has been moved at some point in it's history.
Thanks for the clarification. It makes me feel better about using git to see that it does keep the history when you move a file. I could not imagine that it did not.
On 11.12.2013 04:32, Gavin Lambert wrote:
After this change,
git log file
will output a single commit. You can kinda fix this by passing --follow, but you need to do this every time, there's no documented way to have it as default. Further, gitk does not appear to handle this at all, it just shows a single revision (e.g. if run like 'gitk build/virtual-target.jam').
Then, printing past becomes inconvenient:
$ git show 5a0d9820ac6bd4068a1fa3075d45904ed5341675:build/virtual-target.jam fatal: Path 'build/virtual-target.jam' exists on disk, but not in '5a0d9820ac6bd4068a1fa3075d45904ed5341675'
It is possible to use v2/build/virtual-target.jam in this case, but it's becoming not funny. And, importantly, given that a few people said that rename should "just work", which is demonstrably false, I suspect that there are further gotchas beyond the above immediate ones.
I admit to being a git novice but I am truly shocked that moving a file to another place in a repository through some git command does not keep all of the previous history. Maybe someone who knows git can explain why this is so but it sure seems to me to be a totally erroneous way of treating a move.
AFAICT from discussion above, Git behaves the same as SVN, except that SVN defaults to following moves (and --stop-on-copy disables that) and Git defaults to not following moves (and --follow enables that).
That's important usability difference, IMO.
It's just as painful in SVN to view the contents of a past file through a copy/move/delete, until you get experienced with peg revisions or you use an interactive repository browser to view the whole tree as it appeared in the past.
I believe in SVN, you only need to bother with peg revision in order to identify the object you want to work with, in case it does not exist in current place, or it was a different object with the same name in past. In other cases, SVN will walk the history just fine. E.g. I just run this in SVN: ~/Sources/boost-trunk/tools/build/v2/engine$ svn diff -c18888 jam.c and got a diff. This is an old revision, the 'engine' directory did not exist back then, and until revision 64010, and the file itself was moved twice. So, moving files is in fact easier in SVN. (I vaguely believe that in early SVN versions, the above command would have required peg revision, but it's was long time ago). - Volodya
On 10 December 2013 16:36, Mathias Gaunard <mathias.gaunard@ens-lyon.org> wrote:
On 10/12/13 16:45, Vladimir Prus wrote:
As I've said on Boost.Build mailing list, such a policy or mechanism shall only be in effect after everybody reviews results of the conversion for real, and is happy with them. The conversion was, to a degree, rushed, so we need a time to fix issues before we declare we're really done with the transition to git and start playing by git rules.
Isn't that period over according to the planning? There was a period for library authors to review the history migrated to git.
No, git was only opened at the end of that period. So no one could have modified their repositories during that period, only rejected the conversion outright.
On 10/12/13 15:40, Dave Abrahams wrote:
If there is not already a policy in place to prevent history rewriting in public branches, we should have one. And if there's a GitHub mechanism for denying the privilege, it should be enabled.
Git can do it with an option on the server side, but GitHub does not offer an interface to do it. It could however be possible to contact GitHub support and ask them to do it.
To: boost@lists.boost.org From: dave@boostpro.com Date: Tue, 10 Dec 2013 06:40:23 -0800 Subject: Re: [boost] [git] The any library does not pull cleanly because of a forced update on develop and master.
If there is not already a policy in place to prevent history rewriting in public branches, we should have one. And if there's a GitHub mechanism for denying the privilege, it should be enabled.
I happen to agree with Dave. Is it possible to have a proposal to this effect put before the steering committee and have it voted on? The distinctions between whether it is allowed in general vs only during the 'git transition' and how long that transition lasts should be considered. I'm willing to help with the details of the proposal, but I don't really know the process.
On 12 December 2013 03:44, Ahmed Charles <acharles@outlook.com> wrote:
To: boost@lists.boost.org From: dave@boostpro.com Date: Tue, 10 Dec 2013 06:40:23 -0800 Subject: Re: [boost] [git] The any library does not pull cleanly because of a forced update on develop and master.
If there is not already a policy in place to prevent history rewriting in public branches, we should have one. And if there's a GitHub mechanism for denying the privilege, it should be enabled.
I happen to agree with Dave.
Is it possible to have a proposal to this effect put before the steering committee and have it voted on? The distinctions between whether it is allowed in general vs only during the 'git transition' and how long that transition lasts should be considered.
I'm willing to help with the details of the proposal, but I don't really know the process.
We have to rewrite history because of this: http://lists.boost.org/Archives/boost/2013/08/205491.php It's a bit late to change plans now.
Date: Thu, 12 Dec 2013 09:14:43 +0000 From: daniel@calamity.org.uk To: boost@lists.boost.org Subject: Re: [boost] [git] The any library does not pull cleanly because of a forced update on develop and master.
On 12 December 2013 03:44, Ahmed Charles <acharles@outlook.com> wrote:
To: boost@lists.boost.org From: dave@boostpro.com Date: Tue, 10 Dec 2013 06:40:23 -0800 Subject: Re: [boost] [git] The any library does not pull cleanly because of a forced update on develop and master.
If there is not already a policy in place to prevent history rewriting in public branches, we should have one. And if there's a GitHub mechanism for denying the privilege, it should be enabled.
I happen to agree with Dave.
Is it possible to have a proposal to this effect put before the steering committee and have it voted on? The distinctions between whether it is allowed in general vs only during the 'git transition' and how long that transition lasts should be considered.
I'm willing to help with the details of the proposal, but I don't really know the process.
We have to rewrite history because of this:
http://lists.boost.org/Archives/boost/2013/08/205491.php
It's a bit late to change plans now.
odeint and predef can both be solved with merging the 'original history' with the 'svn history' and you effectively get both. That's an accurate representation of what will actually happen. I've personally used rewriting history for non-public changes (I think changes on development branches is private) and for reducing the size of certain repositories which contained binary files that shouldn't have been there. I'm just pointing out that there is a difference between 'have to' and 'want to'.
On 12 December 2013 11:08, Ahmed Charles <acharles@outlook.com> wrote:
From: daniel@calamity.org.uk
We have to rewrite history because of this:
http://lists.boost.org/Archives/boost/2013/08/205491.php
It's a bit late to change plans now.
odeint and predef can both be solved with merging the 'original history' with the 'svn history' and you effectively get both. That's an accurate representation of what will actually happen.
We've said they could use their own repo. They shouldn't have to incorporate the subversion history as that will muddy their history, and for what gain? The history in the supermodule will be accurately represented by the submodule reference jumping from one branch to another. Whichever way, the decision was made, and no one opposed the plan. If we'd followed my suggestion then there would be no need for a forced push, but no one agreed with me, so I dropped it.
participants (10)
-
Ahmed Charles -
Antony Polukhin -
Cox, Michael -
Daniel James -
Dave Abrahams -
Edward Diener -
Gavin Lambert -
Mathias Gaunard -
Steven Watanabe -
Vladimir Prus