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

From: Stefan Beller <sbeller@google.com>
Date: Nov 21, 2016, 22:57 UTC
Message-ID: <CAGZ79kbCebHojPDUdHn2mmjUwRe-FOcnJqtoa828PJwC6P5mNw@mail.gmail.com>
In-Reply-To: <xmqqpoloh3xa.fsf@gitster.mtv.corp.google.com>

Show 8 quoted lines

> * 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.
>
>  Will hold to wait for hv/submodule-not-yet-pushed-fix

Which is cooking in next, so we'd want to include this into next as well?

When including this series, we get 2 benefits:
* the cooking of hv/submodule-not-yet-pushed-fix is greatly enhanced as
  more submodule users will make use of it (as it would be the default).
* for non submodule users we would see if the approximated estimation
  if the user cares about submodules produces false positives:

        if (has_submodules_configured || file_exists(git_path("modules")) ||
           (!is_bare_repository() && file_exists(".gitmodules")))
                recurse_submodules = RECURSE_SUBMODULES_CHECK;
        else
                recurse_submodules = RECURSE_SUBMODULES_OFF;

This heuristic was introduced after we got burned and called out by Linus, so I would expect this series to not stress non submodule users any more.

Show 9 quoted lines

>
> * dt/empty-submodule-in-merge (2016-11-17) 1 commit
>  - submodules: allow empty working-tree dirs in merge/cherry-pick
>
>  An empty directory in a working tree that can simply be nuked used
>  to interfere while merging or cherry-picking a change to create a
>  submodule directory there, which has been fixed..
>
>  Waiting for review.

I thought I had reviewed it, will do again and comment.

Show 11 quoted lines

> * bw/grep-recurse-submodules (2016-11-18) 6 commits
>  - grep: search history of moved submodules
>  - grep: enable recurse-submodules to work on <tree> objects
>  - grep: optionally recurse into submodules
>  - grep: add submodules as a grep source type
>  - submodules: load gitmodules file from commit sha1
>  - submodules: add helper functions to determine presence of submodules
>
>  "git grep" learns to optionally recurse into submodules
>
>  Waiting for review.

I did review both off and on list and I think the latest version is good.

Show 14 quoted lines

> * hv/submodule-not-yet-pushed-fix (2016-11-16) 4 commits
>   (merged to 'next' on 2016-11-21 at 1a599af962)
>  + submodule_needs_pushing(): explain the behaviour when we cannot answer
>  + batch check whether submodule needs pushing into one call
>  + serialize collection of refs that contain submodule changes
>  + serialize collection of changed submodules
>
>  The code in "git push" to compute if any commit being pushed in the
>  superproject binds a commit in a submodule that hasn't been pushed
>  out was overly inefficient, making it unusable even for a small
>  project that does not have any submodule but have a reasonable
>  number of refs.
>
>  Will cook in 'next'.

Thanks!

Show 15 quoted lines

>
> * jt/use-trailer-api-in-commands (2016-11-02) 6 commits
>  - sequencer: use trailer's trailer layout
>  - trailer: have function to describe trailer layout
>  - trailer: avoid unnecessary splitting on lines
>  - commit: make ignore_non_trailer take buf/len
>  - SQUASH???
>  - trailer: be stricter in parsing separators
>
>  Commands that operate on a log message and add lines to the trailer
>  blocks, such as "format-patch -s", "cherry-pick (-x|-s)", and
>  "commit -s", have been taught to use the logic of and share the
>  code with "git interpret-trailer".
>
>  What's the doneness of this topic?

From a cursory read (with the SQUASH applied) this seems to be done to me.

Show 6 quoted lines

> * sb/submodule-config-cleanup (2016-11-02) 3 commits
> - submodule-config: clarify parsing of null_sha1 element
> - submodule-config: rename commit_sha1 to commit_or_tree
> - submodule config: inline config_from_{name, path}
>
>  What's the doneness of this topic?

Jake Keller reviewed this and it turns out I was not careful in patch 2/3.

Will resend.

Thanks, Stefan