From: Matt McCutchen <matt@mattmccutchen.net>
To: Stefan Beller <sbeller@google.com>
Cc: git <git@vger.kernel.org>
Subject: Re: "git subtree --squash" interacts poorly with revert, merge, and rebase
Date: Wed, 26 Oct 2016 22:42:10 -0400 [thread overview]
Message-ID: <1477536130.1570.10.camel@mattmccutchen.net> (raw)
In-Reply-To: <CAGZ79kb1bb5e5hKpnkFqLOsPow5xt8zczWmZNxMMt5nA84tf-w@mail.gmail.com>
On Wed, 2016-10-26 at 19:03 -0700, Stefan Beller wrote:
> On Wed, Oct 26, 2016 at 6:52 PM, Matt McCutchen <matt@mattmccutchen.net> wrote:
> > 4. I pushed several dangling submodule pointers before I learned I
> > could set push.recurseSubmodules = check. This isn't the default; each
> > developer has to do it manually. (In theory, I could put such things
> > in a setup script for them to run if they trust me.)
>
> There is a current series in flight/for review that makes "check" default.
> (It is blocked as check has some performance issues when having lots
> of commits to be pushed, so it may take a while and not show up in the
> next release)
Great! One other thing: IIRC, "check" does not distinguish between
different remotes. For example, suppose I fork a project that already
has a submodule and I have a pair of repositories that pull from the
"upstream" repositories and push to "origin" repositories for my
project. Suppose I upgrade to a new upstream version and find that I'm
(temporarily) able to use the upstream submodule without modifications.
The "check" feature won't stop me from pushing a pointer into the
"origin" superproject that points to a commit that exists in the
"upstream" subproject but not the "origin" subproject.
> > 5. Stashing changes to both the superproject and the subproject takes
> > more steps.
>
> True, so you'd want to have a `git stash --recurse-submodules={yes,no}`
> where the command line option is configurable, so you don't have to type
> it all the time?
Sounds good. I'm sure you realize this is not just a matter of running
"git stash" in each submodule because there are many ways the stash
stacks could get out of lockstep. The submodule content needs to be
incorporated into the superproject stash.
> Thanks for pointing out the issues though. they align to what
> we plan on doing for submodules, so ... the plan actually makes
> sense :)
Again, I'm thrilled you're working on this, even if I don't use it on
my current project.
Matt
next prev parent reply other threads:[~2016-10-27 2:42 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
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 [this message]
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=1477536130.1570.10.camel@mattmccutchen.net \
--to=matt@mattmccutchen.net \
--cc=git@vger.kernel.org \
--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).