archive mirror
 help / color / mirror / Atom feed
From: Jacob Keller <>
To: Emily Shaffer <>
Cc: "Git mailing list" <>,
	"Ævar Arnfjörð Bjarmason" <>,
	"Jonathan Nieder" <>,, "Junio C Hamano" <>,
Subject: Re: RFC/Discussion - Submodule UX Improvements
Date: Mon, 19 Apr 2021 12:14:48 -0700	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Fri, Apr 16, 2021 at 4:38 PM Emily Shaffer <> wrote:
> Hi folks,
> 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 in
> that I probably
> should share some of those plans ahead of time. :) So attached is a lightly
> modified version of the doc that we've been working on internally at 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" would look
> like for a user working on a project with submodules. Most of the work 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 :)
>  - Emily
> Background
> ==========
> It's worth mentioning that the main goal that's funding this work is to provide
> an alternative for users whose projects use repo
> ( today. That means that the main
> focus is to try and reach feature parity to repo for an easier transition for
> those who want to switch. As a result, some of the direction below is aimed
> towards learning from what has worked well with repo (but hopefully more
> flexible for users who want to do more, or differently).
> There are also a few things mentioned that are specifically targeted to ease use
> with Gerrit, which is in wide use here at Google (and therefore also a
> consideration we need to make to keep getting paid ;) ).
> Overview
> =======

One thing that I think I didn't see covered when I scanned this, that
is something I find difficult or annoying to resolve is using "blame"
with submodules. I use blame a lot to do code history analysis to
understand how something got to the way it is. (Often this helps
resolve issues or bugs by using new context to understand why an old
change was broken).

It has bothered me in the past when I try to do "git blame
<path/to/submodule>" and I get nothing. Obviously there are ways
around this: you can for example just log the path and get the commit
that changed it most recently, or try to search for when the submodule
was set to a given commit.

A sort of dream I had was a flow where I could do something from the
parent like "git blame <path/to/submodule>/submodule/file" and have it
present a blame of that files contents keyed on the *parent* commit
that changed the submodule to have that line, as opposed to being
forced to go into the submodule and figure out what commit introduced
it and then go back to the parent and find out what commit changed the
submodule to include that submodule commit.

> When the work is completed, users should be able to have a clean, obvious
> workflow when using best practices:
> To download the code, they should be able to run simply git clone
> to download the project and all its submodules;
> if partial clone is configured, they should receive only the objects allowed by
> the filter in their superproject as well as in each submodule.
> To begin working on a feature, from the superproject they can 'git switch -c
> feature', and since the new branch is being created, a new branch 'feature' will
> be created for each submodule, pointing to the submodule's current 'HEAD'. They
> can move to a submodule directory and begin to make changes, and when they
> commit these changes normally with 'git commit' from the submodule directory,
> running git status in the superproject will reflect that a submodule has
> changed. Next, they can switch to a second submodule, making and committing more
> changes.
> When they are ready to send these changes which are ready for review but need to
> be linked together, they can switch back to the superproject, where 'git status'
> indicates that there are changes in both submodules. They can commit these
> changes to the superproject and use 'git push' to send a review; Git will
> recurse into affected submodules and push those submodule commits appropriately
> as well.
> While the user is waiting for feedback on their review, to work on their next
> task, they can 'git switch other-feature', which will checkout the branches
> specified in the superproject commit at the tip of 'other-feature'; now the user
> can continue working as before.
> When it's time to update their local repo, the user can do so as with a
> single-repo project. First they can 'git checkout main && git pull' (or 'git
> pull -r'); Git will first checkout the branches associated with main in each
> submodule, then fetch and merge/rebase in each submodule appropriately. Finally,
> they can 'git switch feature && git rebase', at which time Git will recursively
> checkout the branches associated with 'feature' in each submodule and rebase
> each submodule appropriately.

  parent reply	other threads:[~2021-04-19 19:15 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
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 [this message]
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='' \ \ \ \ \ \ \ \ \

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