From: Christian Couder Date: Mon, 07 Aug 2023 12:41:04 GMT Subject: Re: What's cooking in git.git (Aug 2023, #01; Wed, 2) Message-ID: In-Reply-To: (Sorry I somehow forgot to put the mailing list in Cc: of this.) On Fri, Aug 4, 2023 at 10:15 AM Christian Couder wrote: > > On Wed, Aug 2, 2023 at 10:55 PM Junio C Hamano 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=` 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. > > 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.