Le 29 oct. 2025 à 07:37, Kristoffer Haugsbakk [off-list ref] a écrit :

On Wed, Oct 29, 2025, at 11:10, Patrick Steinhardt wrote:

quoted

quoted

On Tue, Oct 28, 2025 at 09:00:43AM -0700, Junio C Hamano wrote:
Patrick Steinhardt [off-list ref] writes:

[snip]

quoted

quoted

* 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 ;)