Re: What's cooking in git.git (Jun 2017, #04; Tue, 13)

[Jonathan Nieder <jrnieder@gmail.com>]

Jun 13, 2017 at 02:40:16PM -0700, Junio C Hamano wrote:

> * sb/submodule-blanket-recursive (2017-06-01) 9 commits
>   (merged to 'next' on 2017-06-04 at 418bb03032)
>  + builtin/fetch.c: respect 'submodule.recurse' option
>  + builtin/push.c: respect 'submodule.recurse' option
>  + builtin/grep.c: respect 'submodule.recurse' option
>  + Introduce 'submodule.recurse' option for worktree manipulators
>  + submodule loading: separate code path for .gitmodules and config overlay
>  + reset/checkout/read-tree: unify config callback for submodule recursion
>  + submodule test invocation: only pass additional arguments
>  + submodule recursing: do not write a config variable twice
>  + Merge branch 'ab/grep-preparatory-cleanup' into sb/submodule-blanket-recursive
>
>  Many commands learned to pay attention to submodule.recurse
>  configuration.

Yay!

>  It is not known if a simple "yes/no" is sufficient in the longer
>  term, and what should happen when --recurse-submodules option starts
>  taking "recurse into them how?" parameter, though.

Any pointers for where this has been discussed, if anywhere (e.g. was
it in the thread
http://public-inbox.org/git/20170526191017.19155-1-sbeller@google.com)?
I'm hoping that we can make the defaults work well enough that a
simple "true/false" becomes sufficient.

Perhaps this is something that the documentation at
http://public-inbox.org/git/20170607185354.10050-1-sbeller@google.com
can go into, since it is an opinionated piece of documentation that
describes commonalities between submodule-related commands and how
they are meant to fit into a user's daily life.

[...]
> * bw/config-h (2017-06-13) 4 commits
>  - config: don't implicitly use gitdir
>  - config: don't include config.h by default
>  - config: remove git_config_iter
>  - config: create config.h
>
>  Code clean-up.

Patches 1-3 are good to go IMHO.

Patch 4 in pu is marked with my Reviewed-by.  I think it's getting
there but not there yet.  Did some script pull the tag from my reply
to the cover letter?  (I'm asking so that if so I can cooperate better
with such a script in the future and avoid false positive
Reviewed-bys.)

[...]
> * jk/warn-add-gitlink (2017-06-13) 2 commits
>  - t: move "git add submodule" into test blocks
>  - add: warn when adding an embedded repository
>
>  Using "git add d/i/r" when d/i/r is the top of the working tree of
>  a separate repository would create a gitlink in the index, which
>  would appear as a not-quite-initialized submodule to others.  We
>  learned to give warnings when this happens.

Note to self that we may want to put a note about this (and more
generally about the git-series style of caller that creates a GITLINK
entry that is not for a submodule) in the document being written at
http://public-inbox.org/git/20170607185354.10050-1-sbeller@google.com
or in some other document like gitrepository-layout.txt.

[...]
> * ls/github (2017-06-13) 1 commit
>  - Configure Git contribution guidelines for github.com
>
>  Help contributors that visit us at GitHub.
>
>  Will merge to 'next'.

\o/ Thank you.

[...]
> --------------------------------------------------
> [Stalled]
>
> * mg/status-in-progress-info (2017-05-10) 2 commits
>  - status --short --inprogress: spell it as --in-progress
>  - status: show in-progress info for short status
>
>  "git status" learns an option to report various operations
>  (e.g. "merging") that the user is in the middle of.
>
>  cf. <xmqqmvakcdqw.fsf@gitster.mtv.corp.google.com>

Thanks for the poke.  This looks a quite nice change, but I agree with
you about its current state.

Regards,
Jonathan