Why are you tracking branches you don't want to land onto?

Are you routinely publishing code under development into the remote (for example, to "share it" or "create a backup"), particularly under a personal namespace like samking-testing-featurewhatever? If Phabricator supported forking (T10691), would that be a better fit for your use case?

Developers want to push their local branches to GitHub for a variety of reasons:

• so that if their computer dies, their work doesn't disappear
• so that they can work across multiple machines (eg, if they have a separate computer at home vs at work, or if they have a cloud development environment separate from their local workstation)
• to show their work to other people before sending out a Phabricator revision (which they could still do with Phabricator, but some folks feel like they should only use Phabricator once something is ready for formal review)
• because at a previous organization, they always pushed their branches, so they're in the habit of doing it

(Also, I may be misunderstanding the terminology if there's a difference between connecting a local branch to an upstream branch and tracking -- apologies if that is so).

And yes, this is happening under a personal namespace like samking-myfeature -- these branches are intended to be personal and are not intended to be production ready, so we don't need to have code review controls around pushing to them. People freely git push and only worry about sending out an arc diff and arc landing when their code is ready to go to master.

The problem statement in T10691 is something we have run into as well. Our workflow that triggers the email spam is:

git checkout -b samking-myfeature
# wait for a bunch of changes to happen on master
git merge master
git push --set-upstream origin samking-myfeature
# everyone who landed code on master between when samking-myfeature was created and when master was merged into samking-myfeature just got an email

I think, since we only care about diffusion emails on master, though, we could probably configure Track Branches to only track master, which would solve the email spam problem.

I don't fully understand what would be involved in forking repos, but it seems like a fairly heavyweight solution. The folks at my organization don't have a structural problem with how things work that would seem to necessitate a separate forked repo -- pushing local feature branches to GitHub works fine -- the issue is just that developers don't remember that they need to use arc land --onto master if they pushed their feature branch.

Does that make sense?

In T11535#191978, @epriestley wrote:

Why are you tracking branches you don't want to land onto?

We do this fairly often with triangle workflows where the upstream is not the same as the resulting change. For example, for our forked phabricator instance we have

• upstream/master (tracked)
• origin/twitter (default push)

if you have the correct git configuration, both git pull and git push will work in a reasonable way (pull from upstream, push to our origin). This does mean that a manual git pull origin/twitter is required if someone else changes the forked version.

Semi-related git gives bad advice for some workflows if you have push.default set to upstream or`simple`. When you do push do a temporary branch, it will encourage you to use -u which sets the tracking branch.

It is fairly common for us to push WIP branches as a means to share code for debugging, preview changes, get a remote system to build a branch for testing, etc.

Severely needed. .arcconfig should be able to control where things land without arguments. I also question the choice made in D10058 where branch tracking seems to be used as a indicator of a branch created with arc-feature. Since arc-feature is in no way central to arc use, I think it should not be assumed that it will be used. And regular workflows and GUI tools will use git-branch instead, with tracking.

Support for forking is not an answer to this.