Re: What's cooking in git.git (Feb 2020, #04; Mon, 17)

[Elijah Newren <newren@gmail.com>]

On Mon, Feb 17, 2020 at 7:30 PM Elijah Newren <newren@gmail.com> wrote:
>
> On Mon, Feb 17, 2020 at 2:09 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()
> >
> >  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>
> >  cf. <CABPp-BF0SO92wxY-dM14Vxv6BGA5=T=CicdwbiaZ7c9w6-j2jQ@mail.gmail.com>
>
> Yes, sorry.  I was hoping someone familiar with untracked-cache (or
> even just the index format) could comment and provide some pointers,
> but it looks like that won't be happening.  I'll try to dig in this
> week to figure out what to do there.

After some digging around, at least part of the final patch is wrong,
and it points to me having somehow broken something with the untracked
cache in the earlier patches.  (t7063.8 sets up a test where dthree/
and dtwo/ should both be shown as untracked directories by 'git status
--porcelain' but are not.  'git ls-files -o --directory', in contrast,
will show them as untracked.)  I probably won't have time to work on
these until after the Git Merge conference, but I will clearly need to
find and fix the bugs before this series progresses.  Feel free to
drop this series in the meantime if it's easier for you.


> > * en/rebase-backend (2020-02-16) 20 commits
> >  - rebase: rename the two primary rebase backends
> >  - 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.
> >
> >  The last step may be rushing things a bit and may want to be
> >  taken separately.
> >  cf. <pull.679.v5.git.git.1581802602.gitgitgadget@gmail.com>

In contrast, this whole series I think is complete and ready to merge
down.  Both Phillip and Dscho have commented that they agree with the
direction of the final patch, Phillip has reviewed multiple rounds and
sounds happy with it, and most of this series already spent some time
in 'next' during the 2.25 cycle.

> Thanks.  I'm curious, though, what you mean by this last bit -- was it
> just a reflection of my request for folks to comment on whether the
> last patch was wanted?
>
> In my view, taking the last patch separately does not make sense; it
> should either be dropped entirely or taken close to the same time as
> the series...[snip]...if we're going to change the backend names, it'd
> be better to do it sooner (while the cost is negligible) rather than
> later.