8 Dec
2012
8 Dec
'12
11:27 p.m.
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
8 Dec
8 Dec
11:36 p.m.
New subject: [trinity-devel] GIT change
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 
9 Dec
9 Dec
1:15 a.m.
New subject: [trinity-devel] GIT change
On Sunday 09 of December 2012 00:36:13 Timothy Pearson wrote:
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
--
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
2:11 a.m.
New subject: [trinity-devel] GIT change
On Sunday 09 of December 2012 00:36:13 Timothy Pearson
wrote:
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
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 
11 Jan
11 Jan
4:43 p.m.
New subject: [trinity-devel] GIT change
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.
--
NULL && (void)
4363
days inactive
4397
days old
4 comments
4 participants
participants (4)
-
Darrell Anderson -
Nix -
Slávek Banko -
Timothy Pearson