Hi,
I thought I'd respond to some of your questions with my opinion and
pointers, in case it's helpful...
On Fri, Feb 3, 2022 at 21:22 PM Junio C Hamano <gitster@xxxxxxxxx> wrote:
> * jc/doc-log-messages (2022-01-27) 3 commits
> - SubmittingPatches: explain why we care about log messages
> - CodingGuidelines: hint why we value clearly written log messages
> - SubmittingPatches: write problem statement in the log in the present tense
>
> Update the contributor-facing documents on proposed log messages.
>
> Will merge to 'next'?
> source: <20220126234205.2923388-1-gitster@xxxxxxxxx>
I think it looks good.
> * ds/sparse-checkout-requires-per-worktree-config (2022-01-31) 5 commits
> - worktree: copy sparse-checkout patterns and config on add
> - sparse-checkout: set worktree-config correctly
> - config: add repo_config_set_worktree_gently()
> - worktree: create init_worktree_config()
> - Documentation: add extensions.worktreeConfig details
>
> "git sparse-checkout" wants to work with per-worktree configration,
> but did not work well in a worktree attached to a bare repository.
>
> What's the doneness of this one?
> source: <pull.1101.v5.git.1643641259.gitgitgadget@xxxxxxxxx>
I think it's done and ready for next.
Eric and I weighed in quite a bit on this series, and it changed
direction pretty dramatically, and more than once. But we eventually
all came to an agreement about what should be done (the hard part),
and this round implements it. Stolee has diligently fixed or answered
each item I've raised and I'm very happy with this version.
> * en/present-despite-skipped (2022-01-14) 6 commits
> - Accelerate clear_skip_worktree_from_present_files() by caching
> - Update documentation related to sparsity and the skip-worktree bit
> - repo_read_index: clear SKIP_WORKTREE bit from files present in worktree
> - unpack-trees: fix accidental loss of user changes
> - t1011: add testcase demonstrating accidental loss of user modifications
> - Merge branch 'vd/sparse-clean-etc' into en/present-despite-skipped
> (this branch uses vd/sparse-clean-etc.)
>
> In sparse-checkouts, files mis-marked as missing from the working tree
> could lead to later problems. Such files were hard to discover, and
> harder to correct. Automatically detecting and correcting the marking
> of such files has been added to avoid these problems.
>
> Will merge to 'next'?
> source: <pull.1114.v2.git.1642175983.gitgitgadget@xxxxxxxxx>
Victoria says I've addressed all her feedback ("Between the RFC and
this version, you've made the changes I was looking for and answered
any remaining questions I had. This series...looks good to me.")[*].
No one else has chimed in with any issues or questions. I'm probably
biased since it's my series, but I do think this one is ready.
[*] https://lore.kernel.org/git/14b6dbeb-5a12-3ac0-9a0e-9cf2c3a381fe@xxxxxxxxxx/
(Sidenote: The series might look a little scary at first, since I was
originally worried with this series that I was going to need to
introduce some kind of backward compatibility break to get the
necessary fixes, or that the performance cost of the fix might be
high, and there's a super lengthy commit message with rationale
because of that. However, in the end both problems were averted and
it just looks like a cheap and long-overdue fix, but I left the long
rationale I had already written anyway.)
> * en/remerge-diff (2022-02-02) 11 commits
> - diff-merges: avoid history simplifications when diffing merges
> - merge-ort: mark conflict/warning messages from inner merges as omittable
> - show, log: include conflict/warning messages in --remerge-diff headers
> - diff: add ability to insert additional headers for paths
> - merge-ort: format messages slightly different for use in headers
> - merge-ort: mark a few more conflict messages as omittable
> - merge-ort: capture and print ll-merge warnings in our preferred fashion
> - ll-merge: make callers responsible for showing warnings
> - log: clean unneeded objects during `log --remerge-diff`
> - show, log: provide a --remerge-diff capability
> - Merge branch 'ns/tmp-objdir' into en/remerge-diff
> (this branch is used by en/merge-tree.)
>
> "git log --remerge-diff" shows the difference from mechanical merge
> result and the merge result that is actually recorded.
>
> Will merge to 'next'?
> source: <pull.1103.v5.git.1643769457.gitgitgadget@xxxxxxxxx>
Ævar's recent opinion on the state of the series was "I think this is
way past good enough."[*]. He's the only reviewer that has commented
since December, leading me to believe the half-dozen or so other
earlier reviewers since August are content with the current shape.
[*] https://lore.kernel.org/git/220202.868rut8qkf.gmgdl@xxxxxxxxxxxxxxxxxxx/
> * pw/fix-some-issues-in-reset-head (2022-01-26) 14 commits
> - rebase -m: don't fork git checkout
> - rebase --apply: set ORIG_HEAD correctly
> - rebase --apply: fix reflog
> - reset_head(): take struct rebase_head_opts
> - rebase: cleanup reset_head() calls
> - create_autostash(): remove unneeded parameter
> - reset_head(): make default_reflog_action optional
> - reset_head(): factor out ref updates
> - reset_head(): remove action parameter
> - rebase --apply: don't run post-checkout hook if there is an error
> - rebase: do not remove untracked files on checkout
> - rebase: pass correct arguments to post-checkout hook
> - t5403: refactor rebase post-checkout hook tests
> - rebase: factor out checkout for up to date branch
>
> Use an internal call to reset_head() helper function instead of
> spawning "git checkout" in "rebase", and update code paths that are
> involved in the change.
>
> Will merge to 'next'?
> May want to rename the topic branch to "pw/use-in-process-checkout-in-rebase"
> or something before doing so.
> source: <pull.1049.v3.git.1643202349.gitgitgadget@xxxxxxxxx>
This series seems good to me and I think it's ready, but the topic
branch rename sounds good.
