From: Jens Lehmann <Jens.Lehmann@web.de>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: [1.8.0] Recursively checkout, merge and reset populated submodules
Date: Sat, 19 Feb 2011 17:59:19 +0100 [thread overview]
Message-ID: <4D5FF6E7.8090104@web.de> (raw)
In-Reply-To: <7vwrky5f48.fsf@alter.siamese.dyndns.org>
Proposal:
When switching branches, merging or resetting the work tree of
populated submodules should be checked out too according to the
commit recorded in the superproject. Make this the default for
porcelain and optional for plumbing.
The same safety precautions that are used for files in the
superproject apply to the changes present in the submodules,
no local modifications may be overwritten unless -f is used.
When the "update" config option is set to "merge" or "rebase"
the submodule will be left unchanged.
The "update" config option will learn a new value "none" to let
the user turn off this behavior for single submodules. A global
config option and the command line parameter "--recurse-submodules"
will also be added. This change will remove the need to call "git
submodule update" for all populated submodules (except those who
use the "update=merge" or "update=rebase" configuration settings).
Advantages:
* This makes submodules behave like the files in the superproject.
Every time the work tree of the superproject changes, the work
trees of the populated submodules are updated accordingly.
* This is the least surprising behavior for new submodule users.
Risks:
The commands might run longer, for those users who use submodules
to gain performance by putting large and/or many files into
submodules this may be unacceptable. Also people might be
surprised by submodule work trees changing without explicitly
invoking "git submodule update". These commands will now fail in
the presence of changed submodules where they would have
succeeded before.
Migration plan:
Announce the change in behavior and document how to easily configure
the old behavior when needed and enable this functionality in 1.8.0.
next prev parent reply other threads:[~2011-02-19 17:00 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-18 1:02 [1.8.0] Summary of the discussions Junio C Hamano
2011-02-18 2:08 ` Martin von Zweigbergk
2011-02-19 16:40 ` [1.7.5] Let fetch and pull recurse into submodules when new commits are recorded Jens Lehmann
2011-02-21 15:12 ` Marc Branchaud
2011-02-21 17:38 ` Jens Lehmann
2011-02-19 16:59 ` Jens Lehmann [this message]
2011-02-20 6:49 ` [1.8.0] Recursively checkout, merge and reset populated submodules Junio C Hamano
2011-02-21 16:13 ` Marc Branchaud
2011-02-21 18:30 ` Jens Lehmann
2011-02-21 19:56 ` Marc Branchaud
2011-02-21 22:54 ` Jens Lehmann
2011-02-22 0:51 ` Miles Bader
2011-02-22 2:32 ` Phil Hord
2011-02-22 8:11 ` Jens Lehmann
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4D5FF6E7.8090104@web.de \
--to=jens.lehmann@web.de \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.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.
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 NNTP newsgroup(s).