On 03/06/2022 19:27, Taylor Blau wrote:
On Fri, Jun 03, 2022 at 01:37:48PM +0000, Derrick Stolee via GitGitGadget wrote:
This is a feature I've wanted for quite a while. When working on the sparse
index topic, I created a long RFC that actually broke into three topics for
full review upstream. These topics were sequential, so any feedback on an
earlier one required updates to the later ones. I would work on the full
feature and use interactive rebase to update the full list of commits.
However, I would need to update the branches pointing to those sub-topics.
This is really exciting. I'm glad that you're working on it, because I
have also wanted this feature a handful of times over the years.
Yes, thank you Stolee. I agree this will be useful, but I wonder if
users will be confused that --update-refs only updates the branch heads
that happen to be in the todo list, rather than updating all the
branches that contain a rewritten commit. I think the latter is
something we should try to add in the future and so we should take care
to design this topic so that is possible.
This definitely would have come in handy when writing MIDX bitmaps,
where I was often editing a local branch pointing at the final topic,
and then trying to reconstruct all of the intermediate branches after
each rebase. Not ever having to do that again sounds like a delight ;-).
pick 2d966282ff3 docs: document bundle URI standard
pick 31396e9171a remote-curl: add 'get' capability
pick 54c6ab70f67 bundle-uri: create basic file-copy logic
pick 96cb2e35af1 bundle-uri: add support for http(s):// and file://
pick 6adaf842684 fetch: add --bundle-uri option
pick 6c5840ed77e fetch: add 'refs/bundle/' to log.excludeDecoration
exec git update-ref refs/heads/bundle-redo/fetch HEAD 6c5840ed77e1bc41c1fe6fb7c894ceede1b8d730
But I wonder if we can or should delay these update-refs as long as
possible. In particular: what happens if I get past this "exec" line (so
that I've already updated my bundle-redo/fetch branch to point at the
new thing), but decide at some later point to abort the rebase?
Absolutely! There is also the question of what to do if a user skips a
commit that is a branch head. It is not obvious if they just want to
drop that commit from the branch or if they want to skip updating the
ref as well (I guess they can edit the todo list for the latter case).
I think users will expect us to restore bundle-redo/fetch to where it
was before if we end up in that case. Recovering from it manually sounds
like kind of a headache.
What if instead we created labels here, and then delayed all ref updates
to the end by replacing this with:
label bundle-redo/fetch
Instead of using 'label' and 'exec' I'd prefer a new todo list command
('update-ref' or 'update-branch'?) used in place of 'label' that takes a
branch name and updates the branch ref at the end of the rebase. That
would make it easy to do all the updates in a single transaction as you
suggested. Adding exec lines to do this makes the todo list messy and we
have been trying to stop rebase forking all the time.
Best Wishes
Phillip
and then at the end of the todo list we'd add:
exec git update-ref refs/heads/bundle-redo/fetch refs/rewritten/bundle-redo/fetch
If we do all of those ref updates in a single transaction at the end, it
should be much easier to roll back from if desired, and we'd avoid the
aborted-rebase problem entirely.
Thanks,
Taylor
