Re: What's cooking in git.git (Feb 2020, #01; Wed, 5)

From: Elijah Newren <newren@gmail.com>
Date: Feb 6, 2020, 01:32 UTC
Message-ID: <CABPp-BF0SO92wxY-dM14Vxv6BGA5=T=CicdwbiaZ7c9w6-j2jQ@mail.gmail.com>
In-Reply-To: <xmqqpnesfw74.fsf@gitster-ct.c.googlers.com>

On Wed, Feb 5, 2020 at 3:36 PM Junio C Hamano <gitster@pobox.com> wrote:

Show 15 quoted lines

> * en/fill-directory-exponential (2020-01-31) 6 commits
>  - t7063: blindly accept diffs
>  - dir: replace exponential algorithm with a linear one
>  - dir: refactor treat_directory to clarify control flow
>  - dir: fix confusion based on variable tense
>  - dir: fix broken comment
>  - dir: consolidate treat_path() and treat_one_path()
>  (this branch uses en/fill-directory-fixes-more.)
>
>  The directory traversal code had redundant recursive calls which
>  made its performance characteristics exponential wrt the depth of
>  the tree, which was corrected.
>
>  Still RFC?
>  cf. <pull.700.v2.git.git.1580495486.gitgitgadget@gmail.com>

Yes, definitely.  (At least) Two things before it's ready to advance:
  1) Either the last commit needs to be squashed down, or if it's
wrong, the code modified to handle the untracked-cache bits correctly.
I'm hoping someone who's familiar with the untracked-cache (or even
the index format) can sanity check this piece or even just provide a
pointer or two about its purpose, design, etc.
  2) This is a somewhat significant change to how fill_directory()
works, and it's very hard to be confident that nothing is broken by
it.  See the commit message of the second to last commit.  I would
really appreciate another pair of eyes.

If no one responds within a week or so with pointers on the untracked-cache, then I'll dig back in and try to figure out what I can. I'm not sure if anyone will review the general fill_directory() stuff; we may just have to bite the bullet at some point by merging it and then watch out for problems. I'll at least look over it all once again when I look at the untracked-cache stuff before submitting the next re-roll.

Show 27 quoted lines

> * en/rebase-backend (2020-01-17) 19 commits
>  - rebase: change the default backend from "am" to "merge"
>  - rebase: make the backend configurable via config setting
>  - rebase tests: repeat some tests using the merge backend instead of am
>  - rebase tests: mark tests specific to the am-backend with --am
>  - rebase: drop '-i' from the reflog for interactive-based rebases
>  - git-prompt: change the prompt for interactive-based rebases
>  - rebase: add an --am option
>  - rebase: move incompatibility checks between backend options a bit earlier
>  - git-rebase.txt: add more details about behavioral differences of backends
>  - rebase: allow more types of rebases to fast-forward
>  - t3432: make these tests work with either am or merge backends
>  - rebase: fix handling of restrict_revision
>  - rebase: make sure to pass along the quiet flag to the sequencer
>  - rebase, sequencer: remove the broken GIT_QUIET handling
>  - t3406: simplify an already simple test
>  - rebase (interactive-backend): fix handling of commits that become empty
>  - rebase (interactive-backend): make --keep-empty the default
>  - t3404: directly test the behavior of interest
>  - git-rebase.txt: update description of --allow-empty-message
>
>  "git rebase" has learned to use the sequencer backend by default,
>  while allowing "--am" option to go back to the traditional "am"
>  backend.
>
>  Waiting for reviews and/or Acks.
>  cf. <CABPp-BHONuRyt8VJqRuoCF2rGYZ5EhH9KJXQZ3NO69rYwA5J3g@mail.gmail.com>

I would like to give Phillip a bit more time for a final review since he said he'd try to review v4, but it's also been a few weeks and I don't want to delay indefinitely. So if he hasn't responded by your next "What's cooking", I'll probably ask that we just merge it down to next at that time.