git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Emily Shaffer <emilyshaffer@google.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] clone: teach --single-branch and --branch during --recurse
Date: Fri, 17 Jan 2020 16:03:19 -0500	[thread overview]
Message-ID: <20200117210319.GA15460@coredump.intra.peff.net> (raw)
In-Reply-To: <20200116223800.GM181522@google.com>

On Thu, Jan 16, 2020 at 02:38:00PM -0800, Emily Shaffer wrote:

> > I have no idea how common this kind of thing would be, and I expect in
> > most cases your patch would do what people want. But we might need to be
> > better about retrying without those options when the first clone fails.
> 
> Yeah, that's interesting. A retry sounds like a pretty solid approach,
> although if someone's being cautious and using --single-branch I wonder
> if that's really something they want (since that's avoiding grabbing
> extraneous branches).
> 
> I suppose at the very least, --single-branch without --branch should
> become recursive. Whether --branch should become recursive, I'm not
> totally sure.

Yeah, I think it may be worth separating out how to think about the two
options. It's a lot more plausible to me that --single-branch would want
to recurse than --branch.

> The two scenarios I see in conflict are this:
> - Superproject branch "foo"
>   - submodule A branch "foo"
>   - submodule B branch "foo"
> and
> - Superproject branch "foo"
>   - submodule A branch "bar"
>   - submodule B branch "baz"
> 
> If we propagate --branch, the first scenario Just Works, and the second
> scenario requires something like:
> 
>  git clone --recurse-submodules=no --single-branch --branch foo https://superproject
>  git submodule update --init --single-branch --branch bar A/
>  git submodule update --init --single-branch --branch baz B/
> 
> (I guess if the superproject knows what branch it wants for all the submodules,
> you could also just do "git submodule update --init --single-branch" and
> have it go and ask for all of them.)
> 
> If we don't propagate --branch, the second scenario Just Works, and the
> first scenario requires something like:
> 
>  git clone --recurse-submodules=no --single-branch --branch foo https://superproject
>  git submodule update --init --single-branch --branch foo
> 
> (That is, I think as long as 'update' takes --branch, even if it's not
> passed along by 'clone', it should still work OK when delegating to
> everyone.)
> 
> Let me know if I misunderstood what you were worried about.

Right, that's exactly my concern. You're making one case work but
breaking the other.

It really seems like there's no particular reason to assume that the
superproject branch corresponds to the submodule branch (or even
submodules of submodules). I imagine it would in some cases (like trying
to replace the use of "repo" in Android), but that's just one model.

It would make more sense to me to either (or both):

  - make sure that .gitmodules has enough information about which branch
    to use for each submodule

  - offer an extra option for the default branch to use for any
    submodules. This is still not general enough to cover all situations
    (e.g., the bar/baz you showed above), but it at least makes it
    relatively easy to cover the simple cases, without breaking any
    existing ones.

-Peff

  reply	other threads:[~2020-01-17 21:03 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-08 23:19 [PATCH] clone: teach --single-branch and --branch during --recurse Emily Shaffer
2020-01-08 23:39 ` Emily Shaffer
2020-01-09  8:11 ` Jeff King
2020-01-16 22:38   ` Emily Shaffer
2020-01-17 21:03     ` Jeff King [this message]
2020-01-27 22:20       ` Emily Shaffer
2020-01-27 22:49         ` Emily Shaffer
2020-01-27 23:10           ` Jeff King
2020-01-28  1:08             ` Emily Shaffer
2020-01-28  1:31               ` Jeff King
2020-01-28  2:10                 ` Emily Shaffer
2020-01-27 23:00         ` Jeff King
2020-01-28 22:17 ` [PATCH v2] clone: pass --single-branch during --recurse-submodules Emily Shaffer
2020-01-30 10:23   ` Jeff King
2020-02-21  2:53     ` Emily Shaffer
2020-02-21  3:16       ` Jeff King
2020-02-21  3:10   ` [PATCH v3 0/2] propagate --single-branch during clone --recurse-submodules Emily Shaffer
2020-02-21  3:10     ` [PATCH v3 1/2] submodule--helper: use C99 named initializer Emily Shaffer
2020-02-21  5:26       ` Jeff King
2020-02-22 20:13       ` Junio C Hamano
2020-02-21  3:10     ` [PATCH v3 2/2] clone: pass --single-branch during --recurse-submodules Emily Shaffer
2020-02-21  5:28       ` Jeff King

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=20200117210319.GA15460@coredump.intra.peff.net \
    --to=peff@peff.net \
    --cc=emilyshaffer@google.com \
    --cc=git@vger.kernel.org \
    /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).