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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 06/02/2020 01:32, Elijah Newren wrote:
On Wed, Feb 5, 2020 at 3:36 PM Junio C Hamano <gitster@xxxxxxxxx> 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@xxxxxxxxx>

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@xxxxxxxxxxxxxx>

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.

I'm sorry I haven't reviewed them yet, it's at the top of my list but unfortunately I've been wiped out for the last couple of weeks so haven't been able to do it (I was going to look at them today but fell asleep instead...). I'll try and look at them by the middle of next week if I can, I don't want to hold them up any longer than that.

Best Wishes

Phillip



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux