Re: What's cooking in git.git (Aug 2017, #05; Tue, 22)

[Johannes Schindelin]

Hi Nicolas,

On Tue, 19 Sep 2017, Nicolas Morey-Chaisemartin wrote:

> Le 19/09/2017 à 17:43, Johannes Schindelin a écrit :
> >
> > C'mon, don't *try* to misunderstand me.
> >
> > Of course there need to be updates as to the state of patch series.
> >
> > It's just that mails only go *so* far when you need to connect and
> > aggregate information. You need the connection between the original patch
> > series, the latest unaddressed reviews, links to the branches, history of
> > the patch series' iterations, and ideally links to the repositories of the
> > contributors with *their* branch names. And then, of course, your verdict
> > as to the state of the patch series and your expectation what happens
> > next.
> >
> > To relate that, you are using a plain text format that is not well defined
> > and not structured, and certainly not machine-readable, for information
> > that is crucial for project management.
> >
> > What you need is a tool to aggregate this information, to help working
> > with it, to manage the project, and to be updated automatically. And to
> > publish this information continuously, without costing you extra effort.
> >
> > I understand that you started before GitHub existed, and before GitHub was
> > an option, the script-generated What's cooking mail was the best you could
> > do.
> 
> Would something like patchwork fix your need ?

Maybe. Here is the link, for other interested parties:
http://jk.ozlabs.org/projects/patchwork/ and
https://github.com/getpatchwork/patchwork

> They now seems to have a REST API, which means it could probably be
> pluggeg into Junio's scripts and work seemlessly for him (or any other
> happy ML user) while other people can browse through the web interface.

It seems that patchwork's design calls for the communication still being
performed as previously, and just providing a web interface to search a
little more efficiently through the mails containing patch submissions.

Git's mailing list, of course, poses the problem to patchwork that the
status of any patch series is opaque to any automatic system that does not
specifically try to connect the What's cooking dot to the patch mail dots.

Also, a point that came up in a private discussion with another core Git
contributor this week: how many reviewers actually even so much as
test-compile, let alone look at the code in context? I am fairly certain
that none do, *just* because of the shortcomings of the process.

Patchwork would not address this, of course.

In my ideal world (in which there would be world peace, too, so it would
be pretty boring, therefore you should not put much stock into what I am
saying next), the direction would be the other way round: the tool should
not scrape the mailing list and make the results accessible via web
interface. Instead, the tool would let me sidestep the mailing list
altogether, using it just as a lossy communication medium (and keep the
lost information accessible in different ways). SubmitGit "threatened" to
allow me to do this: I could open a PR at https://github.com/git/git and
then hit a button and off it goes. SubmitGit stops there, though; If it
would have continued from there (and did not make the initial step
difficult by requiring some registration not everybody is comfortable
with), it would have fulfilled my wishes. Alas, it is written in Scala,
using a framework I am utterly unfamiliar with, so I could not do anything
about it.

Ciao,
Dscho

Re: What's cooking in git.git (Aug 2017, #05; Tue, 22)

[Johannes Schindelin]

Hi Jonathan,

On Tue, 19 Sep 2017, Jonathan Nieder wrote:

> Johannes Schindelin wrote:
> 
> > To relate that, you are using a plain text format that is not well
> > defined and not structured, and certainly not machine-readable, for
> > information that is crucial for project management.
> >
> > What you need is a tool to aggregate this information, to help working
> > with it, to manage the project, and to be updated automatically. And
> > to publish this information continuously, without costing you extra
> > effort.
> >
> > I understand that you started before GitHub existed, and before GitHub
> > was an option, the script-generated What's cooking mail was the best
> > you could do.
> 
> I think you are subtly (but not directly, for some reason?) advocating
> moving project management for the Git project to GitHub Issues.

No, I don't. I know how cumbersome it would be to move tons of people over
from one type of project management to another.

However, the current situation is not really tenable, is it? It is tedious
for everybody involved. I know Junio defends the status quo, but I cannot
imagine that he really likes it, as too much is too manual and
labor-intensive.

As I mentioned at the GitMerge (which was a bit pointless, because Junio
was not there, not even via Skype), I do not advocate one radical change,
ever.

> For what it's worth:
> 
>  1. I would be happy to see Git adopt a bug tracker.  As we've
> discussed on the list before, I suspect the only way that this is
> going to happen is if some contributors start using a bug tracker
> and keep up with bugs there, without requiring everyone to use it.
> That is how the Linux Kernel project started using
> bugzilla.kernel.org, for example.

I agree that a bug tracker goes a long way. Personally, I feel Bugzilla is
way too clunky to use, but I am pampered. However, I could imagine that
allowing issues to be opened at https://github.com/git/git, and
encouraging bug submissions there for people who really need to be able to
find out very, very quickly what the current state of their bug report is,
would go a long way.

Of course, this would require a commitment by Junio and others to allow
discussions to move to that bug tracker from the mailing list. Once that
willingness is there, this should be a viable alternative to reporting
bugs on the mailing list (and have those reports go unanswered because
they fell off the radar...).

>  2. GitHub Issues is one of my least favorite bug trackers, for what
> it's worth.  If some sub-project of Git chooses to use it, then
> that's great and I won't get in their way.  I'm just providing
> this single data point that approximately any other tracker
> (Bugzilla, JIRA, debbugs, patchwork) is something I'd be more
> likely to use.

My experience with Git for Windows, where I try to live Postel's Law by
accepting bug reports via mailing list and GitHub issues (and earlier
Google Code, when that was still alive and kicking), and to a certain
extent even via Twitter: next to nobody likes sending bug reports via mail.

So to add to your sentiment, I like Bugzilla *less* than GitHub issues,
and the worst bug tracker is a mailing list.

Or maybe you have written a shell script that can answer the question
"which of my reported bugs/submitted patch series are still open?" for
the Git mailing list?

>  3. This advice might feel hopeless, because if the maintainer is not
> involved in the initial pilot, then how does the bug tracker get
> notified when a patch has been accepted?  But fortunately this is
> a problem other people have solved: e.g. most bug trackers have an
> API that can be used to automatically notify the bug when a patch
> with a certain subject line appears on a certain branch.

Yes, I agree. The willingness to see the problem, followed by the
willingness to discuss possible solutions, those two need to be the first
steps.

Ciao,
Dscho

Re: What's cooking in git.git (Aug 2017, #05; Tue, 22)

[Nicolas Morey-Chaisemartin]

Le 19/09/2017 à 17:43, Johannes Schindelin a écrit :
>
> C'mon, don't *try* to misunderstand me.
>
> Of course there need to be updates as to the state of patch series.
>
> It's just that mails only go *so* far when you need to connect and
> aggregate information. You need the connection between the original patch
> series, the latest unaddressed reviews, links to the branches, history of
> the patch series' iterations, and ideally links to the repositories of the
> contributors with *their* branch names. And then, of course, your verdict
> as to the state of the patch series and your expectation what happens
> next.
>
> To relate that, you are using a plain text format that is not well defined
> and not structured, and certainly not machine-readable, for information
> that is crucial for project management.
>
> What you need is a tool to aggregate this information, to help working
> with it, to manage the project, and to be updated automatically. And to
> publish this information continuously, without costing you extra effort.
>
> I understand that you started before GitHub existed, and before GitHub was
> an option, the script-generated What's cooking mail was the best you could
> do.
>
> Ciao,
> Dscho
Hi,

Would something like patchwork fix your need ?
They now seems to have a REST API, which means it could probably be pluggeg into
Junio's scripts and work seemlessly for him (or any other happy ML user) while 
other people can browse
through the web interface.

I used to work with this one:
http://patches.opendataplane.org/project/lng-odp/list/
It is not the best  example as the patch status are pretty much never updated 
on this one.

But it would solve most of the points you raised, while keeping fully 
compatible with the way people actually work (including Junio).

Nicolas

Re: What's cooking in git.git (Aug 2017, #05; Tue, 22)

[Jonathan Nieder]

Johannes Schindelin wrote:

> What you need is a tool to aggregate this information, to help working
> with it, to manage the project, and to be updated automatically. And to
> publish this information continuously, without costing you extra effort.
>
> I understand that you started before GitHub existed, and before GitHub was
> an option, the script-generated What's cooking mail was the best you could
> do.

On second reading, I think you're talking about GitHub's code review
("pull request") feature, not a bug tracker.

There's been some active work (some that you've been involved in, I
believe) on getting information from a GitHub pull request to the
mailing list.  One possibility would be to get information to also go
in the other direction, so people have information about what happened
to their patch in one place.

I can also see why you are directing your attention to the maintainer
for this one, since if the entire project adopts the GitHub Pull
Request workflow, then the complexity and other flaws of such a
two-way sync could be avoided.

Unfortunately the maintainer is not the only person you'd need to
convince.  You'd also need to convince patch authors and reviewers to
move to the new workflow.  There are likely some potential
contributors that this would bring in, that would like to get involved
in the Git project but had been deterred by e.g. the mailing list's
aggressive filtering of any email with an HTML part.  Meanwhile it
would also be a large adjustment for existing contributors, so it's
not risk free.

I personally like how Bazel[1] handles this.  They have two ways to
contribute:

 A. People used to GitHub can use a pull request like they are
accustomed to.

 B. People preferring a more structured code review can use Gerrit.

Having only two ways to contribute means that the code review
information is still easy to archive and search, just like our mailing
list archive.

(Actually, an example I like even more is Akaros[2], which also
appears to accept patch contributions by email.)

Adding new ways for a contributor to submit a patch would mean that we
can experiment with new workflows without getting in the way of people
using an existing one.

Thoughts?
Jonathan

[1] https://bazel.build/contributing.html
[2] https://groups.google.com/forum/#!forum/akaros

Re: What's cooking in git.git (Aug 2017, #05; Tue, 22)

[Jonathan Nieder]

Hi,

Johannes Schindelin wrote:

> To relate that, you are using a plain text format that is not well defined
> and not structured, and certainly not machine-readable, for information
> that is crucial for project management.
>
> What you need is a tool to aggregate this information, to help working
> with it, to manage the project, and to be updated automatically. And to
> publish this information continuously, without costing you extra effort.
>
> I understand that you started before GitHub existed, and before GitHub was
> an option, the script-generated What's cooking mail was the best you could
> do.

I think you are subtly (but not directly, for some reason?) advocating
moving project management for the Git project to GitHub Issues.

For what it's worth:

 1. I would be happy to see Git adopt a bug tracker.  As we've
discussed on the list before, I suspect the only way that this is
going to happen is if some contributors start using a bug tracker
and keep up with bugs there, without requiring everyone to use it.
That is how the Linux Kernel project started using
bugzilla.kernel.org, for example.

 2. GitHub Issues is one of my least favorite bug trackers, for what
it's worth.  If some sub-project of Git chooses to use it, then
that's great and I won't get in their way.  I'm just providing
this single data point that approximately any other tracker
(Bugzilla, JIRA, debbugs, patchwork) is something I'd be more
likely to use.

 3. This advice might feel hopeless, because if the maintainer is not
involved in the initial pilot, then how does the bug tracker get
notified when a patch has been accepted?  But fortunately this is
a problem other people have solved: e.g. most bug trackers have an
API that can be used to automatically notify the bug when a patch
with a certain subject line appears on a certain branch.

Thanks and hope that helps,
Jonathan

Re: What's cooking in git.git (Aug 2017, #05; Tue, 22)

[Johannes Schindelin]

Hi Junio,

On Tue, 19 Sep 2017, Junio C Hamano wrote:

> Johannes Schindelin  writes:
> 
> >> Do you have a concrete suggestion to make these individual entries
> >> more helpful for people who may want go back to the original thread
> >> in doing so?  In-reply-to: or References: fields of the "What's
> >> cooking" report would not help.  I often have the message IDs that
> >> made/helped me make these individual comments in the description;
> >> they alone would not react to mouse clicks, though.
> >
> > Oh gawd, not even more stuff piled onto the mail format. Please stop.
> > ...
> > It probably tries to serve too many purposes at the same time, and
> > thereby none.
> 
> Well, this was started as my attempt to give a public service that shows
> a summary of what is happening in the entire integration tree, as there
> was nothing like that before (and going to github.com and looking at
> 'pu' branch would not give you an easy overview).  As many people
> contribute many topics to the project, complaining that it talks about
> too many topics would not get you anywhere.
> 
> If you find "What's cooking" report not serving your needs, and if no
> one finds it not serving his or her needs, then I can stop sending these
> out, of course, but I am not getting the impression that we are at that
> point, at least not yet.

C'mon, don't *try* to misunderstand me.

Of course there need to be updates as to the state of patch series.

It's just that mails only go *so* far when you need to connect and
aggregate information. You need the connection between the original patch
series, the latest unaddressed reviews, links to the branches, history of
the patch series' iterations, and ideally links to the repositories of the
contributors with *their* branch names. And then, of course, your verdict
as to the state of the patch series and your expectation what happens
next.

To relate that, you are using a plain text format that is not well defined
and not structured, and certainly not machine-readable, for information
that is crucial for project management.

What you need is a tool to aggregate this information, to help working
with it, to manage the project, and to be updated automatically. And to
publish this information continuously, without costing you extra effort.

I understand that you started before GitHub existed, and before GitHub was
an option, the script-generated What's cooking mail was the best you could
do.

Ciao,
Dscho

Re: What's cooking in git.git (Aug 2017, #05; Tue, 22)

[Junio C Hamano]

Johannes Schindelin  writes:

>> Do you have a concrete suggestion to make these individual entries more
>> helpful for people who may want go back to the original thread in doing
>> so?  In-reply-to: or References: fields of the "What's cooking" report
>> would not help.  I often have the message IDs that made/helped me make
>> these individual comments in the description; they alone would not react
>> to mouse clicks, though.
>
> Oh gawd, not even more stuff piled onto the mail format. Please stop.
> ...
> It probably tries to serve too many purposes at the same time, and thereby
> none.

Well, this was started as my attempt to give a public service that
shows a summary of what is happening in the entire integration tree,
as there was nothing like that before (and going to github.com and
looking at 'pu' branch would not give you an easy overview).  As
many people contribute many topics to the project, complaining that
it talks about too many topics would not get you anywhere.

If you find "What's cooking" report not serving your needs, and if
no one finds it not serving his or her needs, then I can stop
sending these out, of course, but I am not getting the impression
that we are at that point, at least not yet.

Re: What's cooking in git.git (Aug 2017, #05; Tue, 22)

[Johannes Schindelin]

Hi Junio,

On Sat, 16 Sep 2017, Junio C Hamano wrote:

> And as you alluded to, we may need to see if we can help making it
> easier to do the latter when needed.

That mistakes it for "Someone Else's Problem".

> Johannes Schindelin  writes:
> 
> > That's what you are buying into by having these "What's cooking" mails
> > that are in no usable way connected to the original threads.
> 
> For the above reason, I do not think this is a particularly useful
> stance to take.

I agree, but this is the process you chose to use.

> Do you have a concrete suggestion to make these individual entries more
> helpful for people who may want go back to the original thread in doing
> so?  In-reply-to: or References: fields of the "What's cooking" report
> would not help.  I often have the message IDs that made/helped me make
> these individual comments in the description; they alone would not react
> to mouse clicks, though.

Oh gawd, not even more stuff piled onto the mail format. Please stop.

> Having said that, I'd expect that individual contributors have past
> messages pertaining to the smaller numbers of their own topics in flight
> in their mailbox than the project wide "What's cooking" report covers,
> so perhaps an affort to devise such a mechanism may result in an
> over-engineering waste nobody finds useful.  I dunno.

I frequently find myself putting off that What's cooking mail because it
simply takes too long to study.

It probably tries to serve too many purposes at the same time, and thereby
none.

In the same vein as "to a hammer, everything looks like a nail": when it
comes to project management, a dedicated tool will always beat a
general-purpose mailing list.

Ciao,
Dscho

Re: What's cooking in git.git (Aug 2017, #05; Tue, 22)

[Junio C Hamano]

Johannes Schindelin  writes:

> On Sat, 16 Sep 2017, Junio C Hamano wrote:
>
>> Johannes Schindelin  writes:
>> 
>> > If you want *contributors* to ping the thread themselves, how about
>> > *posting your updates there, too*?
>> 
>> I do not understand this comment at all.  That is what I and others
>> already and always do by responding to the patches, and when trying
>> to see if a topic is still alive, with thread-specific responses and
>> pings.
>> 
>> If you are demanding that "What's cooking" report to be sent as a
>> response to all the topics, that will *NOT* going to happen.  It is
>> meant to give a summary of the current state to help contributors
>> and reviewers be aware of what is happening across the entire tree
>> and not limited to a specific topic.
>
> If that is the case, you will have to be okay with others responding to
> your "What's cooking" mails instead of the original threads.

Yes and no.  When I say "This topic waits for a reroll" and somebody
(not necessarily the author of the topic) wants to remind me that a
reroll has already been posted (or worse--I queued the updated
version but forgot to update the message), I do appreciate that the
reply is made to the "What's cooking" report.  When there is "This
topic waits for a response to a review comment" and the responder
wants to respond to the review comment, the reply should be made in
response to that review comment.  Otherwise, the discussion will
lose the continuity.

And as you alluded to, we may need to see if we can help making it
easier to do the latter when needed.

> That's what
> you are buying into by having these "What's cooking" mails that are in no
> usable way connected to the original threads.

For the above reason, I do not think this is a particularly useful
stance to take.  Do you have a concrete suggestion to make these
individual entries more helpful for people who may want go back to
the original thread in doing so?  In-reply-to: or References: fields
of the "What's cooking" report would not help.  I often have the
message IDs that made/helped me make these individual comments in
the description; they alone would not react to mouse clicks, though.

Having said that, I'd expect that individual contributors have past
messages pertaining to the smaller numbers of their own topics in
flight in their mailbox than the project wide "What's cooking"
report covers, so perhaps an affort to devise such a mechanism may
result in an over-engineering waste nobody finds useful.  I dunno.

Re: What's cooking in git.git (Aug 2017, #05; Tue, 22)

[Johannes Schindelin]

Hi Junio,

On Sat, 16 Sep 2017, Junio C Hamano wrote:

> Johannes Schindelin  writes:
> 
> > If you want *contributors* to ping the thread themselves, how about
> > *posting your updates there, too*?
> 
> I do not understand this comment at all.  That is what I and others
> already and always do by responding to the patches, and when trying
> to see if a topic is still alive, with thread-specific responses and
> pings.
> 
> If you are demanding that "What's cooking" report to be sent as a
> response to all the topics, that will *NOT* going to happen.  It is
> meant to give a summary of the current state to help contributors
> and reviewers be aware of what is happening across the entire tree
> and not limited to a specific topic.

If that is the case, you will have to be okay with others responding to
your "What's cooking" mails instead of the original threads. That's what
you are buying into by having these "What's cooking" mails that are in no
usable way connected to the original threads.

Ciao,
Dscho

Re: What's cooking in git.git (Aug 2017, #05; Tue, 22)

[Junio C Hamano]

Johannes Schindelin  writes:

> If you want *contributors* to ping the thread themselves, how about
> *posting your updates there, too*?

I do not understand this comment at all.  That is what I and others
already and always do by responding to the patches, and when trying
to see if a topic is still alive, with thread-specific responses and
pings.

If you are demanding that "What's cooking" report to be sent as a
response to all the topics, that will *NOT* going to happen.  It is
meant to give a summary of the current state to help contributors
and reviewers be aware of what is happening across the entire tree
and not limited to a specific topic.

Re: What's cooking in git.git (Aug 2017, #05; Tue, 22)

[Johannes Schindelin]

Hi Junio,

On Thu, 24 Aug 2017, Junio C Hamano wrote:

> Lars Schneider  writes:
> 
> > On 22 Aug 2017, at 21:56, Junio C Hamano  wrote:
> >
> >> Here are the topics that have been cooking.  Commits prefixed with
> >> '-' are only in 'pu' (proposed updates) while commits prefixed with
> >> '+' are in 'next'.  The ones marked with '.' do not appear in any of
> >> the integration branches, but I am still holding onto them.
> >> 
> >> The second batch of topics are in.  This cycle is going a bit slower
> >> than the previous one (as of mid-week #3 of this cycle, we have
> >> about 200 patches on 'master' since v2.14, compared to about 300
> >> patches in the cycle towards v2.14 at a similar point in the cycle),
> >> but hopefully we can catch up eventually.  
> >> 
> >> I am planning to be offline most of the next week, by the way.
> >> 
> >> You can find the changes described here in the integration branches
> >> of the repositories listed at
> >> 
> >>http://git-blame.blogspot.com/p/git-public-repositories.html
> >> 
> >> --
> >> [Graduated to "master"]
> >> 
> >
> > Hi Junio,
> >
> > just in case this got lost: I posted a patch with an improvement to 
> > 2841e8f ("convert: add "status=delayed" to filter process protocol", 
> > 2017-06-30) which was merged to master in the beginning of 2.15.
> >
> > https://public-inbox.org/git/20170820154720.32259-1-larsxschnei...@gmail.com/
> 
> Thanks for pinging, but next time ping the thread itself if it is
> about something that is not in What's cooking report you are
> responding to.

If you want *contributors* to ping the thread themselves, how about
*posting your updates there, too*?

It does make things inconvenient for contributors if they have to monitor
those Whats' cooking emails in addition to the mail threads, you know?

Ciao,
Dscho

Re: What's cooking in git.git (Aug 2017, #05; Tue, 22)

[Junio C Hamano]

Lars Schneider  writes:

> On 22 Aug 2017, at 21:56, Junio C Hamano  wrote:
>
>> Here are the topics that have been cooking.  Commits prefixed with
>> '-' are only in 'pu' (proposed updates) while commits prefixed with
>> '+' are in 'next'.  The ones marked with '.' do not appear in any of
>> the integration branches, but I am still holding onto them.
>> 
>> The second batch of topics are in.  This cycle is going a bit slower
>> than the previous one (as of mid-week #3 of this cycle, we have
>> about 200 patches on 'master' since v2.14, compared to about 300
>> patches in the cycle towards v2.14 at a similar point in the cycle),
>> but hopefully we can catch up eventually.  
>> 
>> I am planning to be offline most of the next week, by the way.
>> 
>> You can find the changes described here in the integration branches
>> of the repositories listed at
>> 
>>http://git-blame.blogspot.com/p/git-public-repositories.html
>> 
>> --
>> [Graduated to "master"]
>> 
>
> Hi Junio,
>
> just in case this got lost: I posted a patch with an improvement to 
> 2841e8f ("convert: add "status=delayed" to filter process protocol", 
> 2017-06-30) which was merged to master in the beginning of 2.15.
>
> https://public-inbox.org/git/20170820154720.32259-1-larsxschnei...@gmail.com/

Thanks for pinging, but next time ping the thread itself if it is
about something that is not in What's cooking report you are
responding to.

Re: What's cooking in git.git (Aug 2017, #05; Tue, 22)

[Lars Schneider]

On 22 Aug 2017, at 21:56, Junio C Hamano  wrote:

> Here are the topics that have been cooking.  Commits prefixed with
> '-' are only in 'pu' (proposed updates) while commits prefixed with
> '+' are in 'next'.  The ones marked with '.' do not appear in any of
> the integration branches, but I am still holding onto them.
> 
> The second batch of topics are in.  This cycle is going a bit slower
> than the previous one (as of mid-week #3 of this cycle, we have
> about 200 patches on 'master' since v2.14, compared to about 300
> patches in the cycle towards v2.14 at a similar point in the cycle),
> but hopefully we can catch up eventually.  
> 
> I am planning to be offline most of the next week, by the way.
> 
> You can find the changes described here in the integration branches
> of the repositories listed at
> 
>http://git-blame.blogspot.com/p/git-public-repositories.html
> 
> --
> [Graduated to "master"]
> 

Hi Junio,

just in case this got lost: I posted a patch with an improvement to 
2841e8f ("convert: add "status=delayed" to filter process protocol", 
2017-06-30) which was merged to master in the beginning of 2.15.

https://public-inbox.org/git/20170820154720.32259-1-larsxschnei...@gmail.com/

Thanks,
Lars

Re: What's cooking in git.git (Aug 2017, #05; Tue, 22)

[Brandon Williams]

On 08/22, Junio C Hamano wrote:
> 
> * bw/submodule-config-cleanup (2017-08-03) 17 commits
>  - submodule: remove gitmodules_config
>  - unpack-trees: improve loading of .gitmodules
>  - submodule-config: lazy-load a repository's .gitmodules file
>  - submodule-config: move submodule-config functions to submodule-config.c
>  - submodule-config: remove support for overlaying repository config
>  - diff: stop allowing diff to have submodules configured in .git/config
>  - submodule: remove submodule_config callback routine
>  - unpack-trees: don't respect submodule.update
>  - submodule: don't rely on overlayed config when setting diffopts
>  - fetch: don't overlay config with submodule-config
>  - submodule--helper: don't overlay config in update-clone
>  - submodule--helper: don't overlay config in remote_submodule_branch
>  - add, reset: ensure submodules can be added or reset
>  - submodule: don't use submodule_from_name
>  - t7411: check configuration parsing errors
>  - Merge branch 'bc/object-id' into bw/submodule-config-cleanup
>  - Merge branch 'bw/grep-recurse-submodules' into bw/submodule-config-cleanup
> 
>  Code clean-up to avoid mixing values read from the .gitmodules file
>  and values read from the .git/config file.
> 
>  So, after the recent discussion around submodule..update (and
>  its resolution "use submodule..active; "reset --hard" must
>  ignore the .update thing"), this is now good to go, I presume?
>  Please yell at me that I am clueless if that is not the case ;-)

Yep I came to the same conclusion that you did so this should be good to
go!

-- 
Brandon Williams