Re: What's cooking in git.git (Jun 2017, #04; Tue, 13)
- From
Jonathan Nieder <jrnieder@gmail.com>
- Date
- Jun 14, 2017, 00:52 UTC
- Message-ID
- <20170614005247.GT133952@aiede.mtv.corp.google.com>
- In-Reply-To
- <xmqqshj34ldr.fsf@gitster.mtv.corp.google.com>
Jun 13, 2017 at 02:40:16PM -0700, Junio C Hamano wrote:
Show 14 quoted lines
> * 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.
[...]
Show 7 quoted lines
> * 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.)
[...]
Show 8 quoted lines
> * 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.
[...]
Show 6 quoted lines
> * 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.
[...]
Show 11 quoted lines
> -------------------------------------------------- > [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