Re: [PATCH 0/2] replay: add --update-refs option
- From
Siddharth Asthana <siddharthasthana31@gmail.com>
- Date
- Sep 9, 2025, 06:36 UTC
- Message-ID
- <f4025223-a0ac-416f-b489-d42a07acc0b7@gmail.com>
- In-Reply-To
- <CAP8UFD2XyqgypPfkQav4Fub0AEwyJjXpvfwMPe-adWyCKRa7fQ@mail.gmail.com>
On 08/09/25 11:37, Christian Couder wrote:
Show 31 quoted lines
> On Mon, Sep 8, 2025 at 6:36 AM Siddharth Asthana > <siddharthasthana31@gmail.com> wrote: >> This patch series adds a --update-refs option to git replay. Right now, >> when you use git replay, you need to pipe its output to git update-ref >> like this: >> >> git replay --onto main topic1..topic2 | git update-ref --stdin >> >> This works fine, but it means running two commands and doesn't give you >> atomic transactions by default. The new --update-refs option lets you do >> the ref updates directly: >> >> git replay --update-refs --onto main topic1..topic2 > Thanks for working on this. > >> I discussed this feature with Christian Couder earlier, and we agreed that >> it would be useful for server-side operations where you want atomic updates. > Yeah, right. This is something the Git team at GitLab has been > interested in for some time. > >> The way it works: >> - By default, it uses atomic transactions (all refs get updated or none do) >> - There's a --batch option if you want some updates to succeed even if >> others fail >> - It works with bare repositories, which is important for server operations >> like Gitaly >> - When it succeeds, it doesn't print anything (just like git update-ref >> --stdin) >> - You can't use --update-refs with the existing --update option > There is no existing --update option. This series also introduces the > --update option.
You are right that was confusing wording in my cover letter. Both --update and --update-refs are new in this series.
Show 9 quoted lines
> >> This should help with git replay's goal of being good for server-side >> operations. It also makes the command simpler to use since you don't need >> the pipeline anymore, and the atomic behavior is better for reliability. > I have commented only on the documentation patch for now as I think > it's better to review the design of the new options first, and the > documentation looks like a good place for that. > > Thanks again.