Repository navigation
restack: optional conflict resolution #116
Description
Right now, when we restack, users must resolve all conflicts at restack time.
This is a good default, but it's not always convenient.
An improvement here can be made for multi-branch workflows:
if there's a conflict, present the user an option to pick whether they want to
resolve the conflict now or later.
If they pick now, we let them fix it and run gs rebase continue.
Otherwise, we skip that branch and its upstack from the restack operation,
and print a list of branches that were skipped for them to fix manually later.
Reacted by Jonathan Boiser (JB), stu and james-seymour-cubiko
Activity
s-cork commentedon Aug 7, 2025
This would be very handy, especially with the
gs repo restackcommandsomething like
gs rr --skip-conflictsI've come from graphite where this is the default
they simply log the stacks that were not able to be rebased without conflicts
I have a bunch of stale stacks that i don't plan on working on anytime soon, and that just means i'll never be able to run
gs rrI personally would vote this being the default
with an option to resolve conflicts (--resolve-conflicts)
if
--resolove-conflictsis true, we first restack all stacks that can be restacked without conflictsand then start the conflict resolving.
mvanhorn commentedon Jun 9, 2026
Implemented this in #1235.