Re: Composing git repositories

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Jonathan Nieder <jrnieder@xxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]