Re: What's cooking in git.git (Sep 2021, #08; Mon, 27)

From: Elijah Newren <newren@gmail.com>
Date: Sep 28, 2021, 06:46 UTC
Message-ID: <CABPp-BGuzd_TH57-1RvwJQD5r3S3ZkJcuiPnU8aWee8pgzUBEw@mail.gmail.com>
In-Reply-To: <xmqq8rzhmsi7.fsf@gitster.g>

[Did some slight re-ordering of topics]

On Mon, Sep 27, 2021 at 5:53 PM Junio C Hamano <gitster@pobox.com> wrote:

Show 20 quoted lines

> * ds/add-rm-with-sparse-index (2021-09-24) 13 commits
>  - advice: update message to suggest '--sparse'
>  - mv: refuse to move sparse paths
>  - rm: skip sparse paths with missing SKIP_WORKTREE
>  - rm: add --sparse option
>  - add: update --renormalize to skip sparse paths
>  - add: update --chmod to skip sparse paths
>  - add: implement the --sparse option
>  - add: skip tracked paths outside sparse-checkout cone
>  - add: fail when adding an untracked sparse file
>  - dir: fix pattern matching on dirs
>  - dir: select directories correctly
>  - t1092: behavior for adding sparse files
>  - t3705: test that 'sparse_entry' is unstaged
>
>  "git add", "git mv", and "git rm" have been adjusted to avoid
>  updating paths outside of the sparse-checkout definition unless
>  the user specifies a "--sparse" option.
>
>  Will merge to 'next'?

It would be nice to see the --diff-filter=u change, which you also seemed to like[1]; but after that, yeah this is ready to merge down.

[1] https://lore.kernel.org/git/xmqq35pppwsm.fsf@gitster.g/

Show 20 quoted lines

> * js/scalar (2021-09-14) 15 commits
>  - scalar: accept -C and -c options before the subcommand
>  - scalar: implement the `version` command
>  - scalar: implement the `delete` command
>  - scalar: teach 'reconfigure' to optionally handle all registered enlistments
>  - scalar: allow reconfiguring an existing enlistment
>  - scalar: implement the `run` command
>  - scalar: teach 'clone' to support the --single-branch option
>  - scalar: implement the `clone` subcommand
>  - scalar: implement 'scalar list'
>  - scalar: let 'unregister' handle a deleted enlistment directory gracefully
>  - scalar: 'unregister' stops background maintenance
>  - scalar: 'register' sets recommended config and starts maintenance
>  - scalar: create test infrastructure
>  - scalar: start documenting the command
>  - scalar: create a rudimentary executable
>
>  Add pieces from "scalar" to contrib/.
>
>  Will merge to 'next'?

I feel bad for taking so long to take a look, but I finally responded with a few comments. Mostly, I'm glad it's a contrib thing; a lot of the config makes sense to me (even if some of it is 'meh' for my repository sizes or setup), but two of the config settings would be very objectionable if they were a core git command. Since it's contrib, though, it's probably fine to be very opinionated...and perhaps even excessively so. ;-)

However, since Johannes has been away for a couple weeks, maybe give him a chance to return and respond to myself and others (and perhaps push any updates that occurred to him while on vacation) before merging down?

Show 14 quoted lines

> * en/remerge-diff (2021-08-31) 7 commits
>  - doc/diff-options: explain the new --remerge-diff option
>  - show, log: provide a --remerge-diff capability
>  - tmp-objdir: new API for creating and removing primary object dirs
>  - merge-ort: capture and print ll-merge warnings in our preferred fashion
>  - ll-merge: add API for capturing warnings in a strbuf instead of stderr
>  - merge-ort: add ability to record conflict messages in a file
>  - merge-ort: mark a few more conflict messages as omittable
>
>  A new presentation for two-parent merge "--remerge-diff" can be
>  used to show the difference between mechanical (and possibly
>  conflicted) merge results and the recorded resolution.
>
>  Will merge to 'next'?

It has been a month that it's been cooking with no issues brought up, and it's been in production for nearly a year...

But just this morning I pinged peff and jrnieder if they might have time to respectively look at the tmp-objdir stuff (patch 5, plus its integration into log-tree.c in patch 7) and the ll-merge.[ch] changes (patch 3). I don't know if either will have time to do it, but perhaps wait half a week or so to see if they'll mention they have time? Otherwise, yeah, it's probably time to merge this down.

Show 17 quoted lines

> * en/removing-untracked-fixes (2021-09-27) 12 commits
>  - Documentation: call out commands that nuke untracked files/directories
>  - Comment important codepaths regarding nuking untracked files/dirs
>  - unpack-trees: avoid nuking untracked dir in way of locally deleted file
>  - unpack-trees: avoid nuking untracked dir in way of unmerged file
>  - Change unpack_trees' 'reset' flag into an enum
>  - Remove ignored files by default when they are in the way
>  - unpack-trees: make dir an internal-only struct
>  - unpack-trees: introduce preserve_ignored to unpack_trees_options
>  - read-tree, merge-recursive: overwrite ignored files by default
>  - checkout, read-tree: fix leak of unpack_trees_options.dir
>  - t2500: add various tests for nuking untracked files
>  - Merge branch 'en/am-abort-fix' into en/removing-untracked-fixes
>
>  Various fixes in code paths that move untracked files away to make room.
>
>  Will merge to 'next'?

I just sent out v3 this morning with five new patches (included in your list above). While I think my patches are good, and I'd like to see them merged down to next so I can send my current-working-directory-deletion fixes that build on top of it, I'm a little surprised you're proposing to merge this series down this quickly instead of waiting a little longer for review of the new patches. I'm not complaining...but was that intentional?