Re: [PATCH] refs: support migration with worktrees

[Ben Knoble <ben.knoble@gmail.com>]

> Le 29 oct. 2025 à 07:37, Kristoffer Haugsbakk <kristofferhaugsbakk@fastmail.com> a écrit :
> 
> On Wed, Oct 29, 2025, at 11:10, Patrick Steinhardt wrote:
>>> On Tue, Oct 28, 2025 at 09:00:43AM -0700, Junio C Hamano wrote:
>>> Patrick Steinhardt <ps@pks.im> writes:

[snip]

>>> * If "you must do so from the primary worktree and we convert all
>>>   the worktrees attached to the same repository" is the only mode
>>>   of operation we support (which by the way I have no problem
>>>   with---the first bullet point above was asking question, not
>>>   suggesting change of design), then would it be easier for the
>>>   user to use if the command noticed that it is not in the primary
>>>   worktree and switched to it for the user, instead of complaining
>>>   and failing?
>> 
>> I'm not sure. The question is whether the user recognizes that migrating
>> references in the worktree would also migrate references in the main
>> repository. It might be surprising behaviour if we did that without
>> asking.
> 
> On the contrary, as a user I think it mattering what worktree I run this
> command from sounds very weird.  (But again I can tolerate it requiring
> me to run it from the main worktree if there are technical difficulties/
> limitations.  But using different backends for different
> worktrees is very weird, again.)

[snip]

The fewer concepts we ask a user to manage at a time, likely the better. In this case, “migrate the refs” should probably just work. While things are experimental, rough edges are more tolerable of course, but as we are lifting limitations towards making things official I think polishing such edges is a good idea.

In sum, it can be done later, but I think automatically changing the process directory to the main worktree and carrying on is fine. The curious folks would even see that under the TRACE output ;)