Subject: Re: What's cooking in git.git (Jun 2017, #06; Thu, 22)

From: Ævar Arnfjörð Bjarmason <[email-masked]>
Date: Fri, 23 Jun 2017 00:58:26 +0200

On Thu, Jun 22 2017, Junio C. Hamano jotted:

> * sd/branch-copy (2017-06-18) 3 commits
>  - branch: add a --copy (-c) option to go with --move (-m)
>  - branch: add test for -m renaming multiple config sections
>  - config: create a function to format section headers
>
>  "git branch" learned "-c/-C" to create and switch to a new branch
>  by copying an existing one.
>
>  Has a bit of interaction with two other topics, so perhaps needs to
>  wait for them to stabilize a bit more.

What topics are those? Didn't see any outright conflicts, but might have
missed something. Anything Sahil & I can help with?

> * ab/sha1dc (2017-06-07) 2 commits
>  - sha1collisiondetection: automatically enable when submodule is populated
>  - sha1dc: optionally use sha1collisiondetection as a submodule
>
>  The "collission-detecting" implementation of SHA-1 hash we borrowed
>  from is replaced by directly binding the upstream project as our
>  submodule.
>
>  Will keep in 'pu'.
>  Impact to the various build and release infrastructure of using
>  submodule is not yet fully known, but this lets us dip our toes.

I'm in no rush to get this in. I just submitted it initially as a
"submodules make sense here, and in git.git, yay!"

But it's been 1 month kicking around in pu now. What are we gaining from
keeping it there even longer at this point?

> * bp/fsmonitor (2017-06-12) 6 commits
>  - fsmonitor: add a sample query-fsmonitor hook script for Watchman
>  - fsmonitor: add documentation for the fsmonitor extension.
>  - fsmonitor: add test cases for fsmonitor extension
>  - fsmonitor: teach git to optionally utilize a file system monitor to speed up detecting new or changed files.
>  - dir: make lookup_untracked() available outside of dir.c
>  - bswap: add 64 bit endianness helper get_be64
>
>  We learned to talk to watchman to speed up "git status".
>
>  Waiting for discussion to settle.

Been meaning to do my part to follow-up on this one, sorry about the
delay.

> * xz/send-email-batch-size (2017-05-23) 1 commit
>  - send-email: --batch-size to work around some SMTP server limit
>
>  "git send-email" learned to overcome some SMTP server limitation
>  that does not allow many pieces of e-mails to be sent over a single
>  session.
>
>  Waiting for response.
>  cf. <[email-masked]>

I think between <[email-masked]>
& <20170523103050.1f7ab7e0@jvn> we have sufficient info about what bug
this solves to try an alternate approach at some other time.

I think it makes sense to merge this down.