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

[Elijah Newren <newren@gmail.com>]

On Wed, Feb 5, 2020 at 3:36 PM Junio C Hamano <gitster@pobox.com> wrote:
> * 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.


> * 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.