"Mark Levedahl" <mlevedahl@xxxxxxxxx> writes: > The problem I'm trying to fix is that a number of folks have > superprojects checked out where the recorded origin URL has a trailing > /, and a submodule has its origin in a directory sitting right next to > the superproject on the server. Thus, we have: > > superproject url = server:/public/super > submodoule url = server:/public/sub1 > > However, in the checked out superproject's .git/config > [remote "origin"] > url = server:/public/super/ > > and for similar reasons, the submodule has its URL recorded in .gitmodules as > [submodule "sub"] > path = submodule1 > url = ../sub1/ > > resolve_relative_url gets the submodule's recorded url as $1, which > the caller retrieved from .gitmodules, and retrieves the superprojects > origin from .git/config. So in this case resolve_relative_url has > that: > url = ../sub1/ > remoteurl = server:/public/super/ > > So, without any patch, resolve_relative_url computes the submodule's URL as: > server:/public/super/sub1/ > > with the first patch as: > server:/public/super/sub1 > > and with the second as > server:/public/sub1 > rather than > server:/public/sub1 > > So, the second patch I sent is the one that fixes the above problem, > and I have to say I now forget what the confused state of .gitmodules > + .git/config I found on one machine that lead to the first patch as > being a correct fix. > > In summary, it is essential that resolve_relative_url strip the > trailing / from the superproject's url before starting, while it is > nice but not necessary if it assures that the result does not contain > a trailing /. Well, that is a description worth having in the proposed commit log message, isn't it? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
