On Tue, Aug 22, 2017 at 8:33 AM, Heiko Voigt <hvoigt@xxxxxxxxxx> wrote:
> On Mon, Aug 21, 2017 at 09:42:54AM -0700, Stefan Beller wrote:
>> On Mon, Aug 21, 2017 at 9:05 AM, Heiko Voigt <hvoigt@xxxxxxxxxx> wrote:
>> > On Fri, Aug 18, 2017 at 11:51:13PM -0700, Junio C Hamano wrote:
>> >> As long as we are talking about idealized future world (well, at
>> >> least an idea of somebody's "ideal", not necessarily shared by
>> >> everybody), I wonder if there is even any need to have commits in
>> >> submodules in such a world. To realize such a "monorepo" world, you
>> >> might be better off allowing a gitlink in the superproject to
>> >> directly point at a tree object in a submodule repository (making
>> >> them physically a single repository is an optional implementation
>> >> detail I choose to ignore in this discussion).
>> >
>> > IMO this is one step to far. One main use of submodules are shared
>> > repositories that are used by many superprojects. The reason you want to
>> > have commits in the submodule are so that you can push them
>> > independently and all other users can pick up the changes. You could get
>> > by by Using the superproject commits for the submodule once you push or
>> > something but those do not necessarily make sense in the context of the
>> > submodule.
>> >
>> > So I think it is important that there are commits in the submodule so
>> > its history makes sense independently for others.
>> >
>> > Or how would you push out the history in the submodule in your idea?
>> > Maybe I am missing something? What would be your use case with gitlinks
>> > pointing to trees?
>>
>> Well there are still commits, but in the superproject the UX feels more
>> as if the submodules were special trees.
>
> Ah ok then I misunderstood. So they only feel like trees.
>
>> So if you want to interact with
>> the submodule specifically, you could do things like
>>
>> git add /path/inside/sub
>> # works seamlessly from the superproject tree
>
> Would that mean that we need to loosen/keep the requirement loose for a
> name from .gitmodules? I am asking because of my series for on-demand
> fetch of renamed submodules. For the full functionality I would require
> a name.
>
> Would that be in a scenario where the user would then e.g. push the
> submodule into the superproject?
>
> Ah wait I misunderstood again. You mean a file in an existing
> submodule right? Not adding submodule from a repository a user moved
> there?
Assuming the submodule is at /path in this example, the effect of
that command could be achieved today via
git -C /path add inside/sub
(i.e. for git-add we "just" detect that there is a submodule boundary
and run the git-add inside the submodule)
>
>> git commit --submodule-commit-only
>> # When the flag is not give, you may get an editor
>> # asking for two commit messages, (sub+super)
>
> Or maybe something like
>
> git commit --submodule path/to/submodule
Yes. In todays UX, you do
git -C path/to/submodule commit
for the command that you proposed. For a plain
git-commit in the superproject, we could envision
this sequence of todays commands:
git -C submodule commit
git add submodule
git commit
>
> so the user can specify which submodule she wants. I first wrote it
> without the switch but but that collides with listing files which should
> be added. IMO this shorter option is also more intuitive to understand
> what it does (for this case).
>
>> git fetch --submodule
>> # When the flag is not given, we'd fetch superproject and
>> # on-demand
>
> Yes like above we should add the path to the submodule right?
yes.
>
>> # You feel the superproject is in the way?
>> git worktree add --for-submodule <path/to/sub> ...
>> # The new submodule worktree puts the
>> # submodule only UX first. so it feels like its own
>> # repository, no need for specific flags.
>
> I am not sure I understand this one. What would that do? Put a worktree
> for submodule path/to/sub to ...?
Yes, and at "..." you would have the UX of the submodule being
its own repository, no interaction with the superproject.
>
> Overall I like the direction of these ideas.
>
> Cheers Heiko
