Re: [PATCH v5 00/12] rebase: update branches in multi-part topic

[Derrick Stolee <derrickstolee@github.com>]

On 7/21/2022 12:35 AM, Elijah Newren wrote:
> On Tue, Jul 19, 2022 at 11:33 AM Derrick Stolee via GitGitGadget

>> During review, we have identified some areas that would be good for
>> #leftoverbits:
>>
>>  * Warn the user when they add an 'update-ref ' command but is checked out
>>    in another worktree.
>>  * The checks in patch 9 are quadratic. They could be sped up using
>>    hashtables.
>>  * Consider whether we should include an 'update-ref ' command for the HEAD
>>    ref, so that all refs are updated in the same way. This might help
>>    confused users.
> 
> Not necessarily so they are updated in the same way; the behind the
> scenes mechanism could perhaps still be different.  Just so that if
> the user looks for the "list of things being updated" they don't get
> surprised that HEAD is missing.

Noted.
 
>>  * The error message for failed ref updates could include information on the
>>    commit IDs that would have been used. This can help the user fix the
>>    situation by updating the refs manually.
>>  * Modify the --update-refs option from a boolean to an
>>    optionally-string-parameter that specifies refspecs for the 'update-ref'
>>    commands.
> 
> refspecs?  Is that the term you really mean here?

Probably "ref namespaces" or "ref prefixes" would be better.

>> Updates in v5
>> =============
>>
>>  * Rename 'wt_dir' to 'wt_git_dir' for clarity.
>>  * The documented behavior around 'fixup!' and 'squash!' commits was
>>    incorrect, so update the commit message, documentation, and test to
>>    demonstrate the actual behavior.
>>  * Use CALLOC_ARRAY() to be more idiomatic.
>>  * Be much more careful about propagating errors.
>>  * Commit message typo: "We an" to "We can"
>>  * Remove unnecessary null OID check when writing refs, since those would
>>    already be removed by a previous step.
> 
> Thanks, I've read over the range-diff and these changes look good to
> me.  One thing I'm curious about (sorry to bring this up so late):
> "pick" commands come with the old commit hash.  Perhaps the update-ref
> commands should too?  (e.g. "update-ref refs/heads/topic from
> <OLDHASH>")

I don't personally see the value here other than to make it harder
for someone to add new commands (and confusing when wanting to
create a brand new ref). We could consider adding a comment in the
future without any backwards compatibility issues:

	update-ref refs/heads/my-ref # was 0123dead

Thanks,
-Stolee