git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Stefan Beller <sbeller@google.com>
To: Chris Packham <judge.packham@gmail.com>
Cc: John Smith <johsmi9933@inbox.com>, GIT <git@vger.kernel.org>,
	Jens Lehmann <Jens.Lehmann@web.de>
Subject: Re: Why are submodules not automatically handled by default or at least configurable to do so?
Date: Mon, 26 Oct 2015 09:28:11 -0700	[thread overview]
Message-ID: <CAGZ79kb2kStk0+MqUXREH3g+rqbsXoNiTGj=4SxJ4vOR8TqEcA@mail.gmail.com> (raw)
In-Reply-To: <CAFOYHZAKvN8xMKePCNFgo_ySHr0dc0+ASY0ux7j0p8UF1fuWCQ@mail.gmail.com>

On Sun, Oct 25, 2015 at 5:56 PM, Chris Packham <judge.packham@gmail.com> wrote:
> On Mon, Oct 26, 2015 at 12:10 PM, John Smith <johsmi9933@inbox.com> wrote:
>> I found that I use submodules much, much more often in my git projects than I used externals
>> in Subversion and the reason is that git encourages/forces to organize large projects into
>> smaller repositories, one reason for this being that subversion allows to check out parts of
>> a repository while git does not.
>>
>> But when I clone a git repository with subprojects, I (and everyone else) has to remember to
>> add the --recursive option. When switching between branches with different versions/commits of the
>> submodules everyone has to remember to update the submodules. When updating a submodule
>> everyone has to remember to recurse there too.
>
> The config option fetch.recurseSubmodules exists. It's not quite the
> same as what git clone --recurse-submodules does but it's a start.
>
>>
>> Basically, everything with submodules has to be done manually every time and there seems
>> to be no way to change that default.
>>
>> Why is that? Basically all the time I use submodules I would want automatic handling of
>> submodules to happen and I cannot  remember having had a single situation where I would
>> not have wanted it to happen. So  why does git default to doing nothing?

IIUC at the time submodules were invented, there was need for lots of
code to be written.
Each command needed new code to deal with submodules. As there was not
enough people/time
to do it properly, the "do nothing" was the safest action which could
be added fast.

>
> It's hard to pick a default that suits every workflow that submodules
> support. Also with submodules there is a chicken-and-egg scenario.
> While you can put things in ~/.gitconfig most of what you'd want to
> configure when using submodules would be in super/.git/config but that
> doesn't exist until you've cloned super.git.
>
>> Why does it not provide a way to enable automatic
>> pulling/updating of submodules e.g. when cloning or switching branches?
>
> I believe Jens and Stefan (Cc'd) have been doing some great work in
> this area. Jens even posted his todo list a few days ago
> (https://github.com/jlehmann/git-submod-enhancements/wiki).

Yeah I would also point at Jens' wiki today.

All I did up to now was rewriting parts of the submodule code in C
(git submodule update specifically), while the code/patches you find at Jens'
copy of Git includes already lots of useful stuff such as `git
checkout --recurse-submodules`
(IIRC you don't need to type --recurse-submodules if you configured
that to be the default)

>
>> When would people routinely check out a branch and want to stay with the submodules as
>> the have been checked out for the old branch?

As said above, it was a sane choice which could be implemented fast, IIUC.

I mean what would happen if you had commits made in the submodule, or
just a dirty working tree?

>>
>> I honestly do not understand it.
>>
>> John
>>

Stefan

  reply	other threads:[~2015-10-26 16:28 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-25 23:10 Why are submodules not automatically handled by default or at least configurable to do so? John Smith
2015-10-26  0:56 ` Chris Packham
2015-10-26 16:28   ` Stefan Beller [this message]
2015-10-26 19:53     ` Junio C Hamano
2015-10-26  4:48 ` Nazri Ramliy
2015-10-26 16:56   ` Jens Lehmann
2015-10-28  7:36     ` Nazri Ramliy
2015-10-27 10:50 ` Nick
2015-10-27 10:56   ` Davide Fiorentino
2015-10-27 11:40     ` Nick
2015-10-27 12:16       ` Konstantin Khomoutov

Reply instructions:

You may reply publicly 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 using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAGZ79kb2kStk0+MqUXREH3g+rqbsXoNiTGj=4SxJ4vOR8TqEcA@mail.gmail.com' \
    --to=sbeller@google.com \
    --cc=Jens.Lehmann@web.de \
    --cc=git@vger.kernel.org \
    --cc=johsmi9933@inbox.com \
    --cc=judge.packham@gmail.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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).