From: Peter Williams <pwil3058@bigpond.net.au>
To: Junio C Hamano <gitster@pobox.com>, Stefan Beller <sbeller@google.com>
Cc: Matt McCutchen <matt@mattmccutchen.net>, git <git@vger.kernel.org>
Subject: Re: "git subtree --squash" interacts poorly with revert, merge, and rebase
Date: Thu, 27 Oct 2016 14:23:20 +1000 [thread overview]
Message-ID: <f07745f8-d0ff-c41f-fd44-0812757fbd43@bigpond.net.au> (raw)
In-Reply-To: <xmqqk2cuach3.fsf@gitster.mtv.corp.google.com>
On 27/10/16 09:59, Junio C Hamano wrote:
> 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.
next prev parent reply other threads:[~2016-10-27 4:39 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-26 23:07 "git subtree --squash" interacts poorly with revert, merge, and rebase Matt McCutchen
2016-10-26 23:23 ` Stefan Beller
2016-10-26 23:59 ` Junio C Hamano
2016-10-27 4:23 ` Peter Williams [this message]
2016-10-27 5:46 ` Junio C Hamano
2016-10-27 6:00 ` Junio C Hamano
2016-10-27 1:52 ` Matt McCutchen
2016-10-27 2:03 ` Stefan Beller
2016-10-27 2:42 ` Matt McCutchen
2016-11-10 21:53 ` Matt McCutchen
2016-11-14 22:37 ` Matt McCutchen
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=f07745f8-d0ff-c41f-fd44-0812757fbd43@bigpond.net.au \
--to=pwil3058@bigpond.net.au \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=matt@mattmccutchen.net \
--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
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).