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
As you hinted with "complications" below, I have to wonder what
should happen when the above "git add" touches anything outside
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