archive mirror
 help / color / mirror / Atom feed
From: "Randall S. Becker" <>
To: "'Emily Shaffer'" <>, <>
Cc: <>, <>, <>,
	<>, <>
Subject: RE: RFC/Discussion - Submodule UX Improvements
Date: Mon, 19 Apr 2021 08:56:32 -0400	[thread overview]
Message-ID: <00dc01d7351b$6ffc6500$4ff52f00$> (raw)
In-Reply-To: <>

> -----Original Message-----
> From: Emily Shaffer <>
On April 16, 2021 7:37 PM, Emily Shaffer wrote:
> As hinted by a couple recent patches, I'm planning on some pretty big
> submodule work over the next 6 months or so - and Ævar pointed out to me
> that I
> probably should share some of those plans ahead of time. :) So attached is
> lightly modified version of the doc that we've been working on internally
> Google, focusing on what we think would be an ideal submodule workflow.
> I'm hoping that folks will get a chance to read some or all of it and let
us know
> what sounds cool (or sounds extremely broken). The best spot to start is
> probably the "Overview" section, which describes what the "main path"
> look like for a user working on a project with submodules. Most of the
> that we're planning on doing is under the "What doesn't already work"
> headings.
> Thanks in advance for any time you spend reading/discussing :)
<big snip>

Just adding my voice here, this is something my teams would be very happy to

> - Worktrees
> When a user runs 'git worktree add' from the superproject, each submodule
>  in the new worktree should also be created as a worktree of the
>  submodule in the original project.
> What doesn't already work:
>   * worktrees and submodules getting along - submodules are now freshly
>     when creating a superproject worktree

My teams are currently debating the use of submodules (we have gone back and
forth over the years on these) and worktrees (which seem to have some
positive process implications for those more legacy-ish team members more
used to a centralised workflows). I have not seen any worktree/submodule
combinations used but fear the worst - as in I'm pretty sure I know which of
my team members is going to try this. It is probably a separate matter to
make the two get along better.


-- Brief whoami:
NonStop developer since approximately 211288444200000000
UNIX developer since approximately 421664400
-- In my real life, I talk too much.

  parent reply	other threads:[~2021-04-19 12:56 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-16 23:36 RFC/Discussion - Submodule UX Improvements Emily Shaffer
2021-04-18  5:22 ` Christian Couder
2021-04-20 23:10   ` Emily Shaffer
2021-04-19  3:20 ` Philippe Blain
2021-04-20 23:03   ` Emily Shaffer
2021-04-20 23:30     ` Junio C Hamano
2021-04-21  2:27     ` Philippe Blain
2021-04-19 12:56 ` Randall S. Becker [this message]
2021-04-19 12:56 ` Aaron Schrab
2021-04-20 18:49   ` Emily Shaffer
2021-04-20 19:29     ` Randall S. Becker
2021-04-19 19:14 ` Jacob Keller
2021-04-19 19:28   ` Randall S. Becker
2021-04-20 16:18     ` Jacob Keller
2021-04-20 18:47       ` Emily Shaffer
2021-04-20 19:38         ` Randall S. Becker
2021-04-21  6:57         ` Jacob Keller
2021-04-22 15:32 ` Jacob Keller

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='00dc01d7351b$6ffc6500$4ff52f00$' \ \ \ \ \ \ \ \ \

* 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).