{"thread":{"id":"29022","subject":"What to do if the path of my git submodules change upstream","startedAt":"2011-11-26T16:45:35Z","lastAt":"2011-11-26T16:45:35Z","messageCount":1,"participants":["Harald Heigl"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"179987","messageId":"002d01ccac5a$d2286ac0$76794040$@heigl-online.at","threadId":"29022","inReplyTo":null,"subject":"What to do if the path of my git submodules change upstream","fromName":"Harald Heigl","fromEmail":"harald@heigl-online.at","sentAt":"2011-11-26T16:45:35Z","receivedAt":"2011-11-26T16:45:35Z","isPatch":false,"sender":{"key":"harald@heigl-online.at","avatar":null},"body":"\n> Hi everyone!\n> \n> First setup of my git was a server (with ssh) and some clients.\n> \n> Today I changed to gitolite because I wanted a more sophisticated way of\n> managing my repos. So far so good…\n> So the old path “ssh://[ip]/[fullpath].git” would change to a new path\n> “git@[servername]:[gitreponame]”.\n> This is no problem for “normal” repos, I change the remote origin and\n> continue using push and pull.\n> \n> I have some submodules:\n> I changed the .gitmodules to reflect my changes, did a git submodule sync.\n> This works flawlessly too!\n> \n> But what if someone wants to checkout an older version of the project?\n(for\n> comparison, or because he/she wanted to try something out)\n> He would get an old .gitmodules with old paths.\n> After a git submodule sync he would get errors, because old paths won’t\n> work anymore, because I changed some paths on the server\n> \n> It is only one project I have this problem and therein I changed the\n> .gitmodules only 3 times. Is it possible to rewrite .gitmodules on these\n> specific  commits on the server (perhaps with git-filter-branch)?\n> Or is there another easy solution? Has someone ever had this problem?\n> \n> Hope you can help,\n> Kind regards,\n> Harald Heigl\n\n\nHi everyone!\nI try to answer myself, I found a possibility to change the file\n\".gitmodules\" in my git history:\n\n---------------\nMethod 1 with some git plumbing:\n\ncd [gitrepo]\ncd ..\n[prepare my \"new\" .gitmodules-File here]\ncd [gitrepo]\ngit hash-object -w ../.gitmodules\ngit filter-branch --index-filter 'git rm --cached --ignore-unmatch\n.gitmodules;git update-index --add --cacheinfo 100644 \\\n    3e0f4ab4126e01d55fda040234e3593aea1bff79 .gitmodules'\n022d9c5fecb4d6c268365dfe186aa65389bcd492^..\nPush this new branch to a remote repo and clone from there again (so I'll\nhave a sober dir, without the old branches)\n\nMore or less this adds a new object to git (with SHA1 3e0f4ab in my case)\nand then rewrites every index to remove my old .gitmodules and add the newly\nentered .gitmodules.\n\nThe only \"problem\" is that this will rewrite all Commits and therefore also\nthe SHA1 which won't match the one on the server. \nAs my understanding in git is now: After a change of the (already pushed)\ncommits I'll have to delete the remote repo, push my changed repo upstream\nand then everyone in the team will have to clone this new repo. Good that\nthis project affects only a small group in my company. \n\n------------\nMethod 2 with git rebase -i:\ngit rebase -i 022d9c5fecb4d6c268365dfe186aa65389bcd492^\n\nThis will rebase anything and I can rewrite my file on the specific commits.\nBut this will change my whole history (and SHAs too). If there are some\nmerges in these commit the rebase would flatten anything. This wouldn't\ndisturb that way, but leads to conflicts I have to resolve on the rebase\nside for every commit that conflicts.\n ------------\n\nI'll think over it, if I use Method 1 or don't change anything. Perhaps the\nlatter would be the best :-)\n\nHope this helps others,\nKind regards\n"}]}