Re: RFC/Discussion - Submodule UX Improvements

From: Jacob Keller <jacob.keller@gmail.com>
To: "Randall S. Becker" <rsbecker@nexbridge.com>
Cc: "Emily Shaffer" <emilyshaffer@google.com>,
	"Git mailing list" <git@vger.kernel.org>,
	"Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
	"Jonathan Nieder" <jrnieder@gmail.com>,
	"Albert Cui" <albertcui@google.com>,
	"Junio C Hamano" <gitster@pobox.com>,
	"Matheus Tavares Bernardino" <matheus.bernardino@usp.br>
Subject: Re: RFC/Discussion - Submodule UX Improvements
Date: Tue, 20 Apr 2021 09:18:05 -0700	[thread overview]
Message-ID: <CA+P7+xrOuhG5ujQRYS0=o7S9=xD5zm6BGp5mBRt493Lme9xYcw@mail.gmail.com> (raw)
In-Reply-To: <013401d73552$287f49e0$797ddda0$@nexbridge.com>

On Mon, Apr 19, 2021 at 12:28 PM Randall S. Becker
<rsbecker@nexbridge.com> wrote:
> On April 19, 2021 3:15 PM, Jacob Keller wrote:
> > 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.
>

Well, I would like if "git blame <path/to/submodule>" did.. something
other than just fail. Sometimes my brain is working in a "blame where
this came from" and I type that out and then get frustrated when it
fails. Additionally...

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

I'm not asking for "git blame <path/to/submodule>/<file>" to give the
the same outout as "cd <path/to/submodule> && git blame <file>"

What i'm asking is: given this file, tell me which commit in the
parent did the line get introduced. So basically I want to walk over
the changes to the submodule pointer and find out when it get
introduced into the parent, not when it got introduced into the
submodule itself.

This is a related question, but it is actually not trivial to go
instantly from "it was in xyz submodule commit" to "it was then pulled
in by xyz parent commit". It's something that is quite tedious to do
manually, especially since the submodule pointer could change
arbitrarily so knowing the submodule commit doesn't mean you can
simply grep for which commit set the submodule exactly to that commit.
Essentially, I want a 'git blame' that ignores all changes which
aren't actually the submodule pointer, update.

I think that's something that is much harder to do manually, but feels
like it should be relatively simple to implement within the blame
algorithm. I don't feel like this is something strictly replaceable by
"git submodule foreach"

>
> Randall
>