Jonathan Nieder <jrnie...@gmail.com> writes: > Ramkumar Ramachandra wrote: > >> Even then, working with one worktree embedded >> inside another is something git never designed for: it explains why I >> have to literally fight with git when using submodules > > Do you mean that you wish you could ignore subrepository boundaries > and use commands like > > git clone --recurse-submodules http://git.zx2c4.com/cgit > cd cgit > vi git/cache.h > ... edit edit edit ... > git add --recurse-submodules git/cache.h > git commit --recurse-submodules > git push --recurse-submodules > > , possibly with configuration to allow the --recurse-submodules to be > implied, and have everything work out well? > ... > I think something like that is a goal for submodules in the long > term,...
As you hinted with "complications" below, I have to wonder what should happen when the above "git add" touches anything outside "git" subdirectory. But such an administrative details (the project boundary is primarily not an implementation detail but is a social issue) aside, I agree that overall it would be a good user experience. I however do not see the implementation detail of having (or not having) separate $GIT_DIR for component projects having anything to do with the goal of that ideal. Where and how do you envision the metainformation about the component projects are stored in such a clone? It does not have to be cgit/.git, but you would need to somehow store things we store in $GIT_DIR for cgit itself and git in the current system. If you pick one location to store both, I would imagine that it would still be somewhere under the cgit directory. As I said in another thread, your top-level may be only a part in somebody else's project, and what you consider just a part of your project may be the whole project to somebody else. If you pick one location to store both for the above clone, e.g. cgit/.git (it could be cgit/.ram-git or any other name), embedding it in a yet larger project (perhaps having both cgit and gitolite to give a one-stop solution for hosting services) later would face the same issue as Ram seemed to be complaining. It needs to address what happens when that cgit/.git (or whatever name) gets in the way in the scope of the larger project. That is why I said Ram's rant, using subjective words like "elegant", without sound technical justification, did not make much sense to me. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
