git@vger.kernel.org mailing list mirror (one of many)
 help / Atom feed
From: Heiko Voigt <hvoigt@hvoigt.net>
To: Stefan Beller <sbeller@google.com>
Cc: Junio C Hamano <gitster@pobox.com>, Lars Schneider <larsxschneider@gmail.com>, Brandon Williams <bmwill@google.com>, "git@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: Submodule regression in 2.14?
Date: Tue, 22 Aug 2017 17:33:11 +0200
Message-ID: <20170822153311.GA5697@book.hvoigt.net> (raw)
In-Reply-To: <CAGZ79kZvcY8hawq1qGfFLm1Ukb-wn8j0e_hN8gF5jrEY20o7YA@mail.gmail.com>

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@hvoigt.net> 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?

>     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

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?

>     # 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 ...?

Overall I like the direction of these ideas.

Cheers Heiko

  reply index

Thread overview: 38+ messages in thread (expand / mbox.gz / Atom feed / [top])
2017-08-16 18:35 Lars Schneider
2017-08-16 18:51 ` Stefan Beller
2017-08-16 18:53   ` Stefan Beller
2017-08-17 21:21   ` Lars Schneider
2017-08-17 21:55     ` Stefan Beller
2017-08-18  2:13       ` Junio C Hamano
2017-08-18  4:02         ` Stefan Beller
2017-08-18 16:50           ` Junio C Hamano
2017-08-18 19:09             ` Stefan Beller
2017-08-19  6:51               ` Junio C Hamano
2017-08-21 16:05                 ` Heiko Voigt
2017-08-21 16:42                   ` Stefan Beller
2017-08-22 15:33                     ` Heiko Voigt [this message]
2017-08-22 18:10                       ` Stefan Beller
2017-08-25  9:10                         ` Heiko Voigt
2017-08-25 16:38                           ` Stefan Beller
2017-08-25 16:53                           ` Junio C Hamano
2017-08-21 16:48                   ` Junio C Hamano
2017-08-22 15:50                     ` Heiko Voigt
2017-08-21 16:46                 ` Stefan Beller
2017-08-21 22:45                   ` Junio C Hamano
2017-08-18 13:12       ` Lars Schneider
2017-08-18 17:16         ` Stefan Beller
2017-08-18 19:10           ` Junio C Hamano
2017-08-18 22:04             ` [PATCH] pull: respect submodule update configuration Stefan Beller
2017-08-18 22:05               ` Stefan Beller
2017-08-19  6:17                 ` Junio C Hamano
2017-08-19  6:24               ` Junio C Hamano
2017-08-21 16:20                 ` Heiko Voigt
2017-08-21 16:55                   ` Stefan Beller
2017-08-21 17:20                     ` Lars Schneider
2017-08-21 17:48                       ` Stefan Beller
2017-08-21 18:21                         ` Brandon Williams
2017-08-21 22:52                           ` Junio C Hamano
2017-08-22 14:50                           ` Lars Schneider
2017-08-22 17:51                             ` Stefan Beller
2017-08-22 18:55                               ` Brandon Williams
2017-08-19 18:24           ` Submodule regression in 2.14? Lars Schneider

Reply instructions:

You may reply publically to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply to all the recipients using the --to, --cc,
  and --in-reply-to switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170822153311.GA5697@book.hvoigt.net \
    --to=hvoigt@hvoigt.net \
    --cc=bmwill@google.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=larsxschneider@gmail.com \
    --cc=sbeller@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

git@vger.kernel.org mailing list mirror (one of many)

Archives are clonable:
	git clone --mirror https://public-inbox.org/git
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

Newsgroups are available over NNTP:
	nntp://news.public-inbox.org/inbox.comp.version-control.git
	nntp://ou63pmih66umazou.onion/inbox.comp.version-control.git
	nntp://czquwvybam4bgbro.onion/inbox.comp.version-control.git
	nntp://hjrcffqmbrq6wope.onion/inbox.comp.version-control.git
	nntp://news.gmane.org/gmane.comp.version-control.git

 note: .onion URLs require Tor: https://www.torproject.org/
       or Tor2web: https://www.tor2web.org/

AGPL code for this site: git clone https://public-inbox.org/ public-inbox