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

[Derrick Stolee <derrickstolee@github.com>]

On 7/4/22 10:58 AM, Elijah Newren wrote:
> 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?

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