DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=from:to:cc
        :subject:references:date:in-reply-to:message-id:mime-version
        :content-type; q=dns; s=sasl; b=c/tgwVjxD3nIXDGxIgNwcuxjpB7KXH+j
        yD3X0HHUXdRZCe9HJQ7iBk0qyz5W7xmS6S5jhRoW46lPkhtrBPTZCw3SlIxddCMb
        IdbAPHHYEAa6F+ZAhE7/jDLbNYngmF2CpGkpjJlxhDKcPY38d7JMzuC7CcQ/CNZ+
        ckn/ZJkQXp4=
From:   Junio C Hamano <gitster@pobox.com>
To:     Jonathan Tan <jonathantanmy@google.com>
Cc:     Stefan Beller <sbeller@google.com>, git@vger.kernel.org
Subject: Re: [RFD] Long term plan with submodule refs?
References: <20171108143646.2e1870a82360072557094e01@google.com>
        <20171109001007.11894-1-sbeller@google.com>
        <20171108172945.33c42a0e91b4ac494217b788@google.com>
Date:   Thu, 09 Nov 2017 14:47:10 +0900
In-Reply-To: <20171108172945.33c42a0e91b4ac494217b788@google.com> (Jonathan
        Tan's message of "Wed, 8 Nov 2017 17:29:45 -0800")
Message-ID: <xmqq7ev0j95t.fsf@gitster.mtv.corp.google.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Sender: git-owner@vger.kernel.org
Precedence: bulk

Jonathan Tan <jonathantanmy@google.com> writes:

> What if, in the submodule, we have a new ref backend that mirrors the
> superproject? When initializing the submodule, its original refs are not
> cloned at all, but instead virtual refs are used.
> ...
> These rules seem straightforward to me (although I have been working
> with Git for a while, so perhaps I'm not the best judge), and I think
> leads to a good workflow, as discussed below.

Indeed this is intriguing.

> The above rules allow the following workflow:
>  - "checkout --recurse-submodules" the branch you want on the
>    superproject
>  - make whatever changes you want in each submodule
>  - commit each individual submodule (which updates the index of the
>    superproject), then commit the superproject (we can introduce a
>    commit --recurse-submodules to make this more convenient)

The "recurse" option would also give users an extra atomicity, and
would not be merely for convenience; when a user wants to treat a
superproject and its two submodules as if the combined whole were a
single repository, there shouldn't be two separate commits in the
history of the superproject only because two submodules made one
commit each to work on a single theme that spans all of them.