Re: What's cooking in git.git (Nov 2016, #06; Mon, 28)

[Stefan Beller <sbeller@google.com>]

On Mon, Nov 28, 2016 at 4:15 PM, Junio C Hamano <gitster@pobox.com> wrote:
>
> * sb/push-make-submodule-check-the-default (2016-10-10) 2 commits
>  - push: change submodule default to check when submodules exist
>  - submodule add: extend force flag to add existing repos
>
>  Turn the default of "push.recurseSubmodules" to "check" when
>  submodules seem to be in use.
>
>  Need to rebase on hv/submodule-not-yet-pushed-fix and then consider
>  merging to 'next'.

The rebase is without merge conflicts, so I assume there is no
work needed by me here.

> * sb/submodule-intern-gitdir (2016-11-22) 5 commits
>  - SQUASH
>  - submodule: add embed-git-dir function
>  - test-lib-functions.sh: teach test_commit -C <dir>
>  - submodule helper: support super prefix
>  - submodule: use absolute path for computing relative path connecting
>
>  A new submodule helper "git submodule embedgitdirs" to make it
>  easier to move embedded .git/ directory for submodules in a
>  superproject to .git/modules/ (and point the latter with the former
>  that is turned into a "gitdir:" file) has been added.
>
>  Need to read it over again, deal with SQUASH, and may ask for a
>  reroll.

Ok, I looked over it again and I may see some issues:
* it is applicable to all submodules recursive by default, i.e. really
  "all submodules reachable from this superproject". I anticipate
  this to be the most relevant use case (i.e. as a preparatory step
  for having e.g. git-checkout work), but there are no other commands
  yet that are recursing into submodules recursively by default. So
  a discussion/disagreement on the default may come up.
  (We also may want to see a --[no-]recursive flag)

* The output is okay-ish, but could be better as it is a mix of
  relative and absolute path:

    Migrating git directory of plugins/cookbook from
    '/absolute/path/here/gerrit/plugins/cookbook/.git' to
    '/absolute/path/here/gerrit/.git/modules/plugins/cookbook/'

  On the other hand this seems like what the user may need,
  as it is the maximum for trouble shooting

* As this is a subcommand we do not need to add it to command-list.txt
  However we may want to discuss if some submodule commands are
  porcelain (all except for the new embedgitdirs?) and if this new command
  is plumbing. We could also argue the submodule--helper (which needs
  listing in command-list.txt as a plumbing command?) is the plumbing
  equivalent and the "submodule embedgitdirs" is the porcelain.

* any other part where we need to add documentation for a new command?

FYI: I have a series cooking internally that adds a new page in
Documentation/submodules that introduces the concept of submodules,
which then allows Documentation/git-submodule.txt to be focused on the
actual command and its options.

>
> * dt/empty-submodule-in-merge (2016-11-17) 1 commit
>  - submodules: allow empty working-tree dirs in merge/cherry-pick
>
>  Waiting for review

That slipped by me. Will review.

> * sb/attr (2016-11-11) 35 commits
>  - completion: clone can initialize specific submodules
>  - clone: add --init-submodule=<pathspec> switch
>  - submodule update: add `--init-default-path` switch

I may end up rerolling these top three patches as its own series
again without the underlying pathspec support.

I will investigate if we need the mutex at all for the attribute
code or if we can initialize all attrs (in the pathspecs) before the
threaded preload_index takes place. That sounds cleaner to me,
but I do not prioritize it as high.

>  Waiting for review.

There was some review by Duy and Brandon, I may reroll with just their
issues addressed.

Thanks,
Stefan