Page MenuHomePhabricator

Arcanist tries to land onto identical remote branch instead of 'master'
Closed, DuplicatePublic

Description

In our development process we often push feature branches to the repository server before they are ready for review. This way our CI server can automatically run all kinds of integration tests that take too long to run on a developer's machine. Once the branch is ready for review we do an arc diff, which works fine.

However, when trying to land the branch arc will get confused and tries to land the branch onto it's remote copy. It seems that because the local branch now tracks a remote branch, arc assumes it'll have to be landed onto that remote branch.

$ arc land
Landing current branch 'mybranch'.
 TARGET  Landing onto "mybranch", 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/mybranch...
Usage Exception: There are no commits on "mybranch" which are not already present on the target.

I would expect arc to identify the remote branch as an identical mirror of the local branch and instead land onto the local parent branch.

Event Timeline

Why does the local branch track the remote branch? Do you push using --set-upstream? If so, why?

How would you expect arc to distinguish this case from the cases described in T9657, and particularly T9537 and T9658?

I'm not sure actually. Most of us use GUI tools like Sourcetree or Git Tower, which automatically set up tracking when a branch is pushed. I guess they do this to be able to show the "Commits behind / ahead" badges on branches.

If it needs to be possible to land directly onto a remote branch, it'll indeed be difficult to distinguish the cases. Two ideas:

  • Differential shows that a branch is "branched from X". I don't know if arc is aware of this information, but maybe it could try to look for this branch if it turns out there are no new commits that can be landed onto the tracking branch?
  • Some kind of .arcconfig setting to "never land stuff directly on a remote branch"

Have you asked Sourcetree or Git Tower to change their behavior instead? They can compute ahead/behind without setting tracking, and it seems like setting tracking is not really correct here (the local branches do not really "track" temporary remote CI branches in the traditional sense).

Generally, I'm very hesitant to use "will the push change anything" as a signal, because I think this is unintuitive and will create confusing false negatives. Specifically, if you do this:

  • Push for CI.
  • Notice and fix a typo, amending the local branch.
  • Do not update CI again, since you only fixed a doc typo.
  • arc land

...we would then detect that the local and tracked remote differ, and do the "wrong" thing according to your expectations.

(We could detect this case and fail with an error, but the root issue here seems to be that tracking is being set on a remote branch which the local branch really does not track.)

I guess you're right. We've never really questioned the behaviour of these GUI tools. We assumed that because they do this automatically and provide no way to disable it "they'll probably know what they're doing".

I'll open an issue at their issue tracker.

I've contacted Atlassian about this. They told me Sourcetree tracks branches automatically to cope with git's push.default setting. By default this is set to 'simple', which means git will push the current branch to a tracked remote branch that has the same name as the local branch.

It's possible to set it to 'current' (push current branch to any remote branch with the same name as the local branch), but Sourcetree will continue to track your branches anyway. They might change this in the future: https://jira.atlassian.com/browse/SRCTREE-3988

This is a problem for us too. People push branches to work on it on another machine.

Frankly I don't understand how tracking your own branch on remote is considered abnormal. Git complains about not tracking. Even more so, this "land onto upstream" behavior overriding .arcconfig is weird.

It's abnormal in Phabricator. I use arc patch to work from multiple machines.

@chad: arc-patch requires a diff and pushing a branch is much simpler than creating a diff. Since we seem to be pushed into the direction of an official Phabricator workflow, is that documented somewhere? Phabricator makes assumptions about code structure, versioning and many kinds of things, but are they stated somewhere?

Thanks for the link. That's rather conceptual though. And things like overriding upstream landing is a thing that breaks compatibility with underlying SCM by assuming you use arc-feature. A tool specific explanation of the workflow would be great, for understanding the point of why things work the way they do. Though I'd rather the Official Workflow did not prevent other workflows. But I guess I have the power to remove that feature.

If other workflows means pushing to the remote, T5000 is the plan. Functionally we don't feel " just push whatever" to the remote scales once you hit enterprise scale. The remote becomes polluted with junk branches.

I'm going to merge this into T11535 since it's basically the same issue.