Page MenuHomePhabricator

Make it possible for arc land to disable upstream branch tracking
Closed, WontfixPublic


Upstream branch tracking for git repos was added in Thus, if I push my local branch (git push --set-upstream origin mybranch) and then try to arc land, it will try to land onto origin/mybranch.

At my organization, we always want to land to master. Eg, arc land --onto master would always be the correct command to run for our use case.

Because developers often keep branches local without pushing them, many aren't in the habit of using --onto master because that is the default behavior. As a result, it is unintuitive for them that something doesn't work when they try to arc land after having pushed their feature branch.

It would be great if there were a way to add some configuration setting to the repo's .arcconfig file that specifies "no, we don't want to land onto the upstream branch -- we always want to land to master" so that developers don't need to remember to always pass the --onto master flag when they push. This would work similar to except it would take precedence over the tracked upstream branch.


Event Timeline

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?

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.

eadler added a project: Restricted Project.Sep 15 2016, 6:03 PM

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.

epriestley claimed this task.

After near-future changes connected to T13546, (previously has higher priority than upstream branches.

I plan to introduce arc save and arc load in the future to provide tools for the "save changes" use case, but currently believe it is unlikely that I will add configuration options specifically to support saving changes by pushing them to temporary branches in the remote. I'm open to re-examining this use case after arc save and arc load exist. See also T13426.