Developers, please delete and re-download the top-level GIT
supermodule.
I have temporarily locked out commit access to that top level
supermodule
to prevent accidental merges of the old history. All other GIT
modules
continue to have normal read/write permissions for the TDE
development
team, so the impact of this should be minimal.
Supermodule? Delete exactly what directory in the tree?
Darrell
Developers, please delete and re-download the top-level GIT
supermodule.
I have temporarily locked out commit access to that top level
supermodule
to prevent accidental merges of the old history. All other GIT
modules
continue to have normal read/write permissions for the TDE
development
team, so the impact of this should be minimal.
Supermodule? Delete exactly what directory in the tree?
Darrell
The easiest way I have found to do this is: cd tde mv .git .git.bkp git clone http://scm.trinitydesktop.org/scm/git/tde mv tde/.git . rm -rf tde cp -Rp .git.bkp/config .git/config rm -rf .git.bkp git reset --hard HEAD git pull git submodule init git submodule update
Tim
On Sunday 09 of December 2012 00:36:13 Timothy Pearson wrote:
Developers, please delete and re-download the top-level GIT
supermodule.
I have temporarily locked out commit access to that top level
supermodule
to prevent accidental merges of the old history. All other GIT
modules
continue to have normal read/write permissions for the TDE
development
team, so the impact of this should be minimal.
Supermodule? Delete exactly what directory in the tree?
Darrell
The easiest way I have found to do this is: cd tde mv .git .git.bkp git clone http://scm.trinitydesktop.org/scm/git/tde mv tde/.git . rm -rf tde cp -Rp .git.bkp/config .git/config rm -rf .git.bkp git reset --hard HEAD git pull git submodule init git submodule update
Tim
Newer versions of GIT store git folders for submodules to .git/modules at the top level .git folder. In this procedure would have been destroyed.
I may have a simpler procedure:
git pull --rebase
Hereby is performed move to the current HEAD == move to new HEAD of newly created repository.
Slavek --
On Sunday 09 of December 2012 00:36:13 Timothy Pearson wrote:
Developers, please delete and re-download the top-level GIT
supermodule.
I have temporarily locked out commit access to that top level
supermodule
to prevent accidental merges of the old history. All other GIT
modules
continue to have normal read/write permissions for the TDE
development
team, so the impact of this should be minimal.
Supermodule? Delete exactly what directory in the tree?
Darrell
The easiest way I have found to do this is: cd tde mv .git .git.bkp git clone http://scm.trinitydesktop.org/scm/git/tde mv tde/.git . rm -rf tde cp -Rp .git.bkp/config .git/config rm -rf .git.bkp git reset --hard HEAD git pull git submodule init git submodule update
Tim
Newer versions of GIT store git folders for submodules to .git/modules at the top level .git folder. In this procedure would have been destroyed.
I may have a simpler procedure:
git pull --rebase
Hereby is performed move to the current HEAD == move to new HEAD of newly created repository.
Slavek
As you can tell I'm still no GIT wizard. ;-) Thanks for the tip!
<rant> GIT sometimes just won't let you do what you want. I tried pretty much any way possible to rebase the supermodule in order to simply collapse the automated updates into one commit each between the manual changes; GIT rebase kept failing on the merges no matter what I tried. After many hours of this I ended up going with a (suboptimal) complete wipe of the master branch followed by a recommit by copying over the .git/index file.
What I would really like to see in GIT is the ability to track submodule HEAD refs in a supermodule without needing to establish a ridiculously long commit history containing every submodule change. </rant>
Tim
On 9 Dec 2012, Timothy Pearson verbalised:
What I would really like to see in GIT is the ability to track submodule HEAD refs in a supermodule without needing to establish a ridiculously long commit history containing every submodule change.
I hate to ask this but... what harm is there in that? git doesn't get harmed at all by very long histories. All you're storing is a few extra hashes.
-
Darrell Anderson -
Nix -
Slávek Banko -
Timothy Pearson