Junio C Hamano <gitster@xxxxxxxxx> writes: > Karthik Nayak <karthik.188@xxxxxxxxx> writes: > >> The 'git-refs(1)' migrate subcommand, which transfers repositories >> between reference backends, currently migrates reflogs by default as of >> 246cebe320 (refs: add support for migrating reflogs, 2024-12-16). >> >> While this behavior is desirable for most client-side repositories, >> server-side repositories are not expected to contain reflogs. However, >> due to historical reasons, some may still have them. This could be >> caused, for example, by bugs, misconfiguration, or an administrator >> enabling reflogs on the server for debugging purposes. >> >> To address this, introduce the --skip-reflog flag, allowing users to >> bypass reflog migration. This ensures that the repository ends up in the >> expected state after migration. >> >> Helped-by: Patrick Steinhardt <ps@xxxxxx> >> Signed-off-by: Karthik Nayak <karthik.188@xxxxxxxxx> >> --- >> Changes in v2: >> - Fix typo in commit mesasge and clarify the intent. >> - Modify the test to use `test_line_count` and `test_must_be_empty`. >> - Link to v1: https://lore.kernel.org/r/20250207-477-refs-migrate-add-a-flag-to-ignore-reflogs-during-migration-v1-1-7d40f3b4e30b@xxxxxxxxx >> --- >> Range-diff versus v1: >> >> 1: ce14d3d07e ! 1: 6b83089348 builtin/refs: add '--skip-reflog' flag to bypass reflog migration >> @@ Commit message >> >> The 'git-refs(1)' migrate subcommand, which transfers repositories >> between reference backends, currently migrates reflogs by default as of >> ... >> + ' >> done >> done >> --- >> builtin/refs.c | 3 +++ >> refs.c | 8 +++++--- >> refs.h | 5 ++++- >> t/t1460-refs-migrate.sh | 19 +++++++++++++++++-- >> 4 files changed, 29 insertions(+), 6 deletions(-) > > This is tangent that is totally unrelated to the theme of this > patch, but I find that the placement of range-diff makes it very > hard to follow. > > After skimming the proposed log message, the next thing I would want > to see is the list of paths that are modified, before deciding I > want to review the patch now. Once I decide to read it _now_, the > changes from the previous iteration and range-diff becomes relevant. > > Is it just me who decides in what order to review the patches and > then reviews them in that order? > > Anyway. > I missed responding to this in my previous email, but I've been using b4 for sending patches and this was primarily due to how it sends single patch series. I've fixed the template to show the diff-stat first, and this should be the case for upcoming patches. Thanks for pointing it out! [snip]
Attachment:
signature.asc
Description: PGP signature
