Re: What's cooking in git.git (Aug 2023, #01; Wed, 2)

>
> On Wed, Aug 2, 2023 at 10:55 PM Junio C Hamano <gitster@pobox.com> wrote:
>
> > * cc/repack-sift-filtered-objects-to-separate-pack (2023-07-24) 8 commits
> >  . gc: add `gc.repackFilterTo` config option
> >  . repack: implement `--filter-to` for storing filtered out objects
> >  . gc: add `gc.repackFilter` config option
> >  . repack: add `--filter=<filter-spec>` option
> >  . repack: refactor finding pack prefix
> >  . repack: refactor finishing pack-objects command
> >  . t/helper: add 'find-pack' test-tool
> >  . pack-objects: allow `--filter` without `--stdout`
> >
> >  "git repack" machinery learns to pay attention to the "--filter="
> >  option.
> >
> >  Breaks CI with some environment variables configured.
> >  cf. <xmqqo7jzh9mh.fsf@gitster.g>
> >  source: <20230724085909.3831831-1-christian.couder@gmail.com>
>
> I am working on this and hope to send a version 4 soon.
>
> > * cc/git-replay (2023-06-03) 15 commits
> >  - replay: stop assuming replayed branches do not diverge
> >  - replay: add --contained to rebase contained branches
> >  - replay: add --advance or 'cherry-pick' mode
> >  - replay: disallow revision specific options and pathspecs
> >  - replay: use standard revision ranges
> >  - replay: make it a minimal server side command
> >  - replay: remove HEAD related sanity check
> >  - replay: remove progress and info output
> >  - replay: add an important FIXME comment about gpg signing
> >  - replay: don't simplify history
> >  - replay: introduce pick_regular_commit()
> >  - replay: die() instead of failing assert()
> >  - replay: start using parse_options API
> >  - replay: introduce new builtin
> >  - t6429: remove switching aspects of fast-rebase
> >
> >  What's the status of this thing?
> >  source: <20230602102533.876905-1-christian.couder@gmail.com>
>
> I have a 2 week long vacation starting soon, so I will likely not have
> time to work on a new round in the next 3 weeks.
>
> However in a recent article
> (https://github.blog/2023-07-27-scaling-merge-ort-across-github/)
> GitHub says that they are already using git-replay (though not sure
> it's this exact version or another one), and GitLab plans to use it
> too. So I guess it's worth keeping.