Re: "git subtree --squash" interacts poorly with revert, merge, and rebase

From: Peter Williams <pwil3058@bigpond.net.au>
Date: Oct 27, 2016, 04:23 UTC
Message-ID: <f07745f8-d0ff-c41f-fd44-0812757fbd43@bigpond.net.au>
In-Reply-To: <xmqqk2cuach3.fsf@gitster.mtv.corp.google.com>

On 27/10/16 09:59, Junio C Hamano wrote:

Show 29 quoted lines

> Stefan Beller <sbeller@google.com> writes:
>
>>> - We have to make separate commits and manage corresponding topic
>>> branches for the superproject and subprojects.
>>
>> Well yeah, that is how submodule work on a conceptual level.
>> While having multiple commits may seem like overhead, note
>> the subtle difference for these commits. One if deep down in the
>> stack patching one of the submodules, the other is a high level
>> commit advancing the submodule pointer.
>>
>> Note that the target audience of these two commit messages
>> might be vastly different, hence can be worded differently.
>> (The submodule describing how you fixed e.g. a memleak or race condition
>> and the superproject describes on why you needed to include that submodule,
>> e.g. because you switched your toplevel application to use threads.)
>
> Both good points.
>
> Another thing to keep in mind is that in a well-organized project,
> it is expected that you would have multiple commits in a submodule,
> solving one single issue that is needed by the superproject in a
> finer grained way, before the resulting submodule tip is recorded in
> the tree of the superproject in one commit.  IOW, between the time
> the superproject's history moves by one commit, the submodule may
> have multiple commits in order for the submodule to become ready to
> be consumed by the superproject.
>
>

I'm a relatively new user of submodules and I quite like them (having 
tried a few other strategies for sharing common code between multiple 
projects and found them quite painful) and find them fairly easy to use. 
  I especially like the fact that the submodule command isn't very 
complicated and that the best method for managing commits, etc in the 
submodule is to cd into their root directory and then treat them like 
any other git repository (greatly reducing the amount of new stuff that 
you have to learn in order to use them).  Also, from my experience so 
far, I see three different types of work going on within my workspaces 
that include submodules:

1. I'm working on changes to the submodule and using the superproject 
that it's checked out in to test those changes in which case most of the 
change is occurring in the submodule with changes in the superproject 
usually being small one related to API changes in the submodule.

2. I'm working on changes in the superproject and the only changes that 
get made in the submodules are to fix bugs uncovered by the work in the 
superproject.

3. I'm modifying a superproject to accommodate changes to a submodule 
that's changed as a result of having changes pulled from another repository.

In none of these cases do I feel the desire/need to commit the changes to the superproject and submodule(s) with a single commit command which more or less agrees with your points.

However, for git commands such as diff/status whose job is to display information it would be nice if they had a --recursive option to override the default submodule diff/status and show details of the changes in the submodules. Sometimes you want to see the big picture in detail.