(Sorry I somehow forgot to put the mailing list in Cc: of this.) On Fri, Aug 4, 2023 at 10:15 AM Christian Couder <christian.couder@xxxxxxxxx> wrote: > > On Wed, Aug 2, 2023 at 10:55 PM Junio C Hamano <gitster@xxxxxxxxx> 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@xxxxxxxxx> > > 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@xxxxxxxxx> > > 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.
