On 7/4/22 10:58 AM, Elijah Newren wrote: > On Mon, Jul 4, 2022 at 6:26 AM Derrick Stolee <derrickstolee@xxxxxxxxxx> wrote: >> >> On 7/1/22 5:08 PM, Junio C Hamano wrote: >> >>> * ds/rebase-update-ref (2022-06-28) 8 commits >>> - rebase: add rebase.updateRefs config option >>> - rebase: update refs from 'update-ref' commands >>> - rebase: add --update-refs option >>> - sequencer: add update-ref command >>> - sequencer: define array with enum values >>> - rebase-interactive: update 'merge' description >>> - branch: consider refs under 'update-refs' >>> - t2407: test branches currently using apply backend >>> (this branch uses ds/branch-checked-out.) >>> >>> "git rebase -i" learns to update branches whose tip appear in the >>> rebased range. >>> >>> Will merge to 'next'? >>> source: <pull.1247.v3.git.1656422759.gitgitgadget@xxxxxxxxx> >> >> Please expect at least one more re-roll. Here are the things I >> intend to fix in the next re-roll, which should arrive sometime >> this week. >> >> * Some commit message tweaks. >> * Actually interrupt 'git bisect' and 'git rebase' in the tests. >> * Be careful to update the update-refs file when the user edits >> the todo file. >> * Consider storing the "before" values in the update-refs file >> and removing refs whose update-ref steps were removed by the >> user. > > First half sounds good to me. Not sure I understand the second half > about "removing refs"; do you mean actually deleting the ref, or just > not updating it, or something else? I mean removing it from the $GIT_DIR/rebase-merge/update-refs file so it is no longer blocking others from using it (and the value in the file can be used for a --force-with-lease type update). >> * Elijah had a question about focusing on "pick" actions, not >> "fixup" or "squash" steps. This might be worth marking the >> option as experimental so we have flexibility in changing the >> behavior as new workflows are tested against this option. > > This sounds good to me. I do sometimes want to fixup or squash into a > commit that a branch I depend upon directly points to, so I'm worried > your feature may update refs incorrectly without this support. I've been using this quite a bit in my own work, and it properly moves fixups and squashes into the right branches, but I've only done that with fixups and squashes on the tip branch, not inside the earlier branches. It's also been really good when I rebase and add "break" or "edit" steps and do really complicated commit squashing or splitting operations. I'll try to collect some example runs, but it would also help a great deal if you added these patches to your local version of Git and try it own in your workflow. Use the rebase.updateRefs=true config setting so you don't need to think about it. Victoria has been testing this for me in her own workflows, so maybe she has ideas here. Thanks, -Stolee
