What to do if the path of my git submodules change upstream

From: Harald Heigl <harald@heigl-online.at>
Date: Nov 26, 2011, 16:45 UTC
Message-ID: <002d01ccac5a$d2286ac0$76794040$@heigl-online.at>

Show 16 quoted lines

> Hi everyone!
> 
> First setup of my git was a server (with ssh) and some clients.
> 
> Today I changed to gitolite because I wanted a more sophisticated way of
> managing my repos. So far so good
> So the old path ssh://[ip]/[fullpath].git would change to a new path
> git@[servername]:[gitreponame].
> This is no problem for normal repos, I change the remote origin and
> continue using push and pull.
> 
> I have some submodules:
> I changed the .gitmodules to reflect my changes, did a git submodule sync.
> This works flawlessly too!
> 
> But what if someone wants to checkout an older version of the project?

(for

Show 13 quoted lines

> comparison, or because he/she wanted to try something out)
> He would get an old .gitmodules with old paths.
> After a git submodule sync he would get errors, because old paths wont
> work anymore, because I changed some paths on the server
> 
> It is only one project I have this problem and therein I changed the
> .gitmodules only 3 times. Is it possible to rewrite .gitmodules on these
> specific  commits on the server (perhaps with git-filter-branch)?
> Or is there another easy solution? Has someone ever had this problem?
> 
> Hope you can help,
> Kind regards,
> Harald Heigl

Hi everyone! I try to answer myself, I found a possibility to change the file ".gitmodules" in my git history:

--------------- Method 1 with some git plumbing:

cd [gitrepo]
cd ..
[prepare my "new" .gitmodules-File here]
cd [gitrepo]
git hash-object -w ../.gitmodules
git filter-branch --index-filter 'git rm --cached --ignore-unmatch
.gitmodules;git update-index --add --cacheinfo 100644 \
    3e0f4ab4126e01d55fda040234e3593aea1bff79 .gitmodules'
022d9c5fecb4d6c268365dfe186aa65389bcd492^..
Push this new branch to a remote repo and clone from there again (so I'll
have a sober dir, without the old branches)

More or less this adds a new object to git (with SHA1 3e0f4ab in my case) and then rewrites every index to remove my old .gitmodules and add the newly entered .gitmodules.

The only "problem" is that this will rewrite all Commits and therefore also the SHA1 which won't match the one on the server. As my understanding in git is now: After a change of the (already pushed) commits I'll have to delete the remote repo, push my changed repo upstream and then everyone in the team will have to clone this new repo. Good that this project affects only a small group in my company.

------------ Method 2 with git rebase -i: git rebase -i 022d9c5fecb4d6c268365dfe186aa65389bcd492^

This will rebase anything and I can rewrite my file on the specific commits.
But this will change my whole history (and SHAs too). If there are some
merges in these commit the rebase would flatten anything. This wouldn't
disturb that way, but leads to conflicts I have to resolve on the rebase
side for every commit that conflicts.
 ------------

I'll think over it, if I use Method 1 or don't change anything. Perhaps the latter would be the best :-)

Hope this helps others, Kind regards