This behavior is intentional and I don't plan to change it.

The common case is novice users on master, tracking origin/master, making commits in their local master with no idea how branches, git or remotes work. I think deleting master would be unreasonably confusing for them.

After D14357, this is documented in arc help land:

The branch which was landed is deleted, unless the **--keep-branch**
flag was passed or the landing branch is the same as the target
branch.

In your advanced workflow, you could sort of work around this by making sure your local branch always has a different name than the remote branch.

T3277 (a future arc cleanup command) might be another approach, although I would probably not cleanup branches which track remotes by default. But maybe an arc cleanup --very-aggressive --destroy-everything could remove all local branches which are not ahead of remotes (although I'm not sure this is what you'd want).

That makes total sense—deleting master seems like a really bad idea in that case.

I might be misunderstanding the documentation or intent here, but what I'm seeing seems like a different case, where the landed branch name is different from the target branch name but the landed branch still doesn't get deleted:

> git checkout -b T9660-example --track origin/master
Branch T9660-example set up to track remote branch master from origin.
Switched to a new branch 'T9660-example'
> rm FOO
> git commit -am "Deleted FOO"
> arc diff
…
> arc land
Landing current branch 'T9660-example'.
 TARGET  Landing onto "master", selected by following tracking branches upstream to the closest remote.
 REMOTE  Using remote "origin", selected by following tracking branches upstream to the closest remote.
 FETCH  Fetching origin/master...
This commit will be landed:

      - 363c473cc2bc Deleted FOO



    Revision 'D91: Deleted FOO' has not been accepted. Continue anyway? [y/N] y

Landing revision 'D91: Deleted FOO'...
 BUILDS PASSED  Harbormaster builds for the active diff completed successfully.
 PUSHING  Pushing changes to "origin/master".
Counting objects: 2, done.
Delta compression using up to 16 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (2/2), 271 bytes | 0 bytes/s, done.
Total 2 (delta 1), reused 0 (delta 0)
To <some server>
   4ab964f72a08..e1bb8d031f44  e1bb8d031f44b19045c815b26fb02ccf2da40eda -> master
Local "master" tracks target remote "origin/master", checking out and pulling changes.
 DONE  Landed changes.
> git branch | grep T9660
  T9660-example

In this situation, since the landed branch name was T9660-example and the target branch name was master, I expected that Arcanist would have deleted T9660-example after landing.

That does look like a bug, let me take a peek.

This does mean we can't distinguish between these cases:

git checkout -b win10 origin/long-cumbersome-branch-name-windows-release-tag-branch-verifed-stable-10.0.0-GOLDMASTER
git checkout -b win10 origin/master

...where the first case is "work with a local branch normally, but use a more convenient name" and the second case is "derive feature branches directly from the remote".

We'll now delete the branch in the first case, assuming it's part of the second case. This is probably not what the user wanted -- in the first case, users likely want to retain the branch, but probably usually branch from it (so they may not ever hit this) and are probably sophisticated enough to recover from it getting deleted if they forget to branch (so the cost to deal with it is probably small).

The overall behavior is also simpler than trying to special case this.

(Let me know if I missed anything, and thanks for the report!)

This is working great now; thanks so much for the fast turnaround!