ds/generation-numbers (was Re: What's cooking in git.git (Jun 2018, #01; Fri, 1))

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

 



On 6/1/2018 3:21 AM, Junio C Hamano wrote:

* ds/commit-graph-lockfile-fix (2018-05-22) 1 commit
   (merged to 'next' on 2018-05-24 at 3d12a02b0c)
  + commit-graph: fix UX issue when .lock file exists
  (this branch is used by ds/commit-graph-fsck; uses ds/generation-numbers.)

  Update to ds/generation-numbers topic.

  Wait for ds/generation-numbers


* ds/generation-numbers (2018-05-22) 11 commits
   (merged to 'next' on 2018-05-24 at 56fc38a1b6)
  + commit-graph.txt: update design document
  + merge: check config before loading commits
  + commit: use generation number in remove_redundant()
  + commit: add short-circuit to paint_down_to_common()
  + commit: use generation numbers for in_merge_bases()
  + ref-filter: use generation number for --contains
  + commit-graph: always load commit-graph information
  + commit: use generations in paint_down_to_common()
  + commit-graph: compute generation numbers
  + commit: add generation number to struct commit
  + ref-filter: fix outdated comment on in_commit_list
  (this branch is used by ds/commit-graph-fsck and ds/commit-graph-lockfile-fix.)

  A recently added "commit-graph" datafile has learned to store
  pre-computed generation numbers to speed up the decisions to stop
  history traversal.

  Will cook in 'next'.

On Wednesday, these were marked as "Will merge to 'master'" What changed?

Thanks,
-Stolee



[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