Re: ds/rebase-update-re (was Re: What's cooking in git.git (Jul 2022, #01; Fri, 1))

[Elijah Newren <newren@gmail.com>]

On Mon, Jul 4, 2022 at 6:26 AM Derrick Stolee <derrickstolee@github.com> 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@gmail.com>
>
> 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?

> * 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.

> * Elijah also had some optimization ideas, but I'm not sure if
>   we should prioritize them here or have them as future
>   improvements after the feature is stable.

You know, thinking about it more, with every single commit, sequencer
already updates the index, the working tree, HEAD, and *several*
control files.  So these optimizations would probably just be lost in
the noise.  Unless we restructure sequencer.c, it may not be worth
implementing these ideas at all.  Either way, I'd say this certainly
shouldn't hold up this series.