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@xxxxxxxxxx)? 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@xxxxxxxxxx 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@xxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxxxxxx> Thanks for the poke. This looks a quite nice change, but I agree with you about its current state. Regards, Jonathan