archive mirror
 help / color / mirror / Atom feed
From: "Randall S. Becker" <>
To: "'Jacob Keller'" <>,
	"'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 15:28:15 -0400	[thread overview]
Message-ID: <013401d73552$287f49e0$797ddda0$> (raw)
In-Reply-To: <>

On April 19, 2021 3:15 PM, Jacob Keller wrote:
> 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.

Not going to disagree, but are you looking for the blame on the submodule ref file itself or files in the submodule? It's hard to teach git to do a blame on a one-line file.

Otherwise, and I think this is what you really are going for, teaching it to do a blame based on "git blame <path/to/submodule>/submodule/file" would be very nice and abstracts out the need for the user (or more importantly to me = scripts) to understand that a submodule is involved; however, it is opening up a very large door: "should/could we teach git to abstract submodules out of every command". This would potentially replace a significant part of the use cases for the "git submodule foreach" sub-command. In your ask, the current paradigm "cd <path/to/submodule>/submodule && git blame file" or pretty much every other command does work, but it requires the user/script to know you have a submodule in the path. So my question is: is this worth the effort? I don't have a good answer to that question. Half of my brain would like this very much/the other half is scared of the impact to the code.

Just my musings.


  reply	other threads:[~2021-04-19 19:28 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
2021-04-19 19:28   ` Randall S. Becker [this message]
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='013401d73552$287f49e0$797ddda0$' \ \ \ \ \ \ \ \ \ \

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