Sorry, I accidentally submitted in the middle of typing :)

and you beat me to it.

T9657 is probably the relevant guidance. There is no way to get the old behavior back.

thanks

In your first example, you can likely:

git branch -f Release1 HEAD # Force Release1 to point at the detached head.

...and then continue like you previously did.

Yes, that will work.

Given that this was the old behavior and there is another request for this, is there a reason why arc can't do this step for us, either based on some configuration flag or potentially maybe not even?
Is there a good use case for a detached case scenario that I'm not taking into consideration here?

Where's the other request for this?

The motivation was this scenario:

You can land onto a remote branch with a local copy of the branch which isn't really that branch but is just some other branch which you've named the same thing as the other branch.

We can't do that if we actually write onto Release1. The original task or tasks are linked from T9657. The new behavior generally remedies a large range of scenarios where users were confused by arc land writing to Release1 when they did not expect it to.

See also T8227.

You can use arc alias to define a new command which runs arc land --hold --onto X && git branch -f X HEAD or similar.

In T10274#157022, @epriestley wrote:

Where's the other request for this?

I was referring to T9973

The motivation was this scenario:

You can land onto a remote branch with a local copy of the branch which isn't really that branch but is just some other branch which you've named the same thing as the other branch.

We can't do that if we actually write onto Release1. The original task or tasks are linked from T9657. The new behavior generally remedies a large range of scenarios where users were confused by arc land writing to Release1 when they did not expect it to.

I think that makes sense for arc land, and as odd a workflow as I find it, I understand the need to support it, but arc land --hold implies modification of local repository, no? Previously arc land --hold was a legitimate workflow that put the user's repository in a very predictable and easy to understand state. Now the end result feels like some process got interrupted in the middle and is really not useful for anything other than pushing. It even kind of looks like a repository that is left in the middle of a failed rebase, with detached heads and unmerged branches. It also leaves garbage branches behind that the user now needs to go clean up manually, and since the branches do not appear merged into trunk, it needs to be a force delete, which is always a little bit of a scary operation, especially for people not experienced with git.
>

See also T8227.

I'm very much with you on that one. That's why I'm suggesting assuming a certain intent behind using arc land --hold and Doing The Right Thing(TM).

You can use arc alias to define a new command which runs arc land --hold --onto X && git branch -f X HEAD or similar.

Yeah, but that requires us to specify the branch to land onto, which is something arc already knows from .arcconfig.

I was referring to T9973

Ah, see T9973#148869.