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

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

[Harald Heigl]

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
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 won’t 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

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

[Harald Heigl]

> 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
> 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 won’t
> 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