Page MenuHomePhabricator

Upgrading: arc land flow has been rewritten in git
Closed, ResolvedPublic


Git workflows in arc land have been completely rewritten to fix issues on a large number of unorthodox or creative flows.

Mercurial, SVN, Git/SVN and Hg/SVN are not affected.

In particular:

  • We try much harder to put you back where you started on failure, instead of stopping in the middle and asking you to resolve things.
  • The author and author date are now preserved.
  • You can land from a detached HEAD.
  • You can land from a tag.
  • You can land a branch onto itself.
  • You can land onto a remote branch without having a local copy of that branch.
  • 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.
  • Upstreams are resolved recursively until we find one in a remote, fail to reach a remote, or are trapped in a cycle.
  • Remote and target selection behavior is now more explicit and more clearly communicated.
  • arc help land is more descriptive and complete.
  • After pushing, we now try to find a path from the local branch to the remote by following branch upstreams. If we can, we update them and then put you on the branch at the end of the path. The exact behavior here is complicated but the expectation is that it should generally do something reasonable no matter what the path between you and the remote is.

If you run into cases on the new flow that don't work well or where the workflow or error behavior are unclear, let us know.

For more context, see T3855, T9537, T8620, T4333, T9543, T9658, T9660 and T9506.

Related Objects

Mentioned In
T9555: Exception with 'arc land' after manually rebasing a revision and resolving conflicts, leaves repository in unclean state
T11362: Arcanist tries to land onto identical remote branch instead of 'master'
T7342: Extend documentation on arc land
T6522: "Commit's branches contains" condition is not re-evaluated for commits in multiple branches
T10274: Did arc land --hold change behavior?
T9973: `arc land` detached head state with `--hold`
T9948: Modernize "arc land" for Mercurial: bookmark-to-branch, branch-to-self, multiple heads
Z1336: General Chat
T9506: arc land's help text doesn't mention default of landing in tracked branch
Blog Post: Development Notes (2015 Week 44)
2015 Week 44 (Very Late October)
T9661: arc land doesn't return to local tracking branch if it has a different name from the remote branch it's tracking
T3855: `arc land` should work when the current branch/bookmark and the target branch/bookmark are the same
Mentioned Here
T8227: Why not just add an option/setting/preference?
T9506: arc land's help text doesn't mention default of landing in tracked branch
T9658: arc land doesn't default --onto to a tracked branch if it is a remote
T9660: arc land does not delete landed branch when landing directly to remote
T3855: `arc land` should work when the current branch/bookmark and the target branch/bookmark are the same
T4333: `arc land` should provide a mechanism to land revisions by other authors while preserving authorship meta-data
T8620: support landing from a detached head in git
T9537: Support for landing without local tracking branch
T9543: In "arc land", recursively resolve tracking branches until we reach one in a remote

Event Timeline

epriestley raised the priority of this task from to Normal.
epriestley updated the task description. (Show Details)
epriestley updated the task description. (Show Details)
epriestley updated the task description. (Show Details)
epriestley added a subscriber: epriestley.

I successfully was able to land onto a remotely tracked branch other than master but hit this:

UPDATE  Local branch "redesign-2015" is not connected to a remote, staying on detached HEAD.

Does this mean that arc doesn't think the branch is being tracked or is there something else I'm missing here? Here is the output from git remote show origin.

* remote origin
  Fetch URL: ssh://git@XXXX
  Push  URL: ssh://git@XXXX
  HEAD branch: master
  Remote branches:
    bw-package      tracked
    graphs2.0       tracked
    ldap-management tracked
    master          tracked
    orders          tracked
    redesign        tracked
    redesign-2015   tracked
    snmptt          tracked
  Local branch configured for 'git pull':
    master merges with remote master
  Local refs configured for 'git push':
    master        pushes to master        (up to date)
    redesign      pushes to redesign      (local out of date)
    redesign-2015 pushes to redesign-2015 (local out of date)

Can you show me this?

$ git rev-parse --symbolic-full-name redesign-2015@{upstream}

Generally, we only care about tracking branches. It looks like your local redesign-2015 doesn't have origin/redesing-2015 as an upstream? What does the [remote] section for it look like in .gitconfig? How did you create the local branch?

Woops. I just assumed that since git remote show origin listed the branch as tracked under remote branches, that it was tracked.

Here's the output from that command:

git rev-parse --symbolic-full-name redesign-2015@{upstream}
error: No upstream branch found for 'redesign-2015'
error: No upstream branch found for 'redesign-2015'
fatal: ambiguous argument 'redesign-2015@{upstream}': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions

I think I did the following when I originally created the branch. It's been a while at this point (it seems that redesigns never end ...).

git checkout -b redesign-2015
git push origin redesign-2015

Also, there is nothing in my .gitconfig about [remote].

If you do this:

$ git push --set-upstream origin redesign-2015

...instead of this:

$ git push origin redesign-2015

...when you push, I think arc will do what you want.

After we push, we're looking for a local branch which tracks the branch we just pushed to (or tracks something which tracks it), so we can git pull it to update your local branch. Since your local redesign-2015 doesn't have the remote redesign-2015 set as an upstream, git pull won't actually work in it. That's why we decline to switch to redesign-2015 -- it would be behind the remote, and we couldn't pull it.

We can't distinguish between this case and a similar case where redesign-2015 is just an arbitrary local branch which happens to have the same name as the branch in the remote for no particular reason. This is a case which came up in one of the attached tasks.

Yep, that was the issue. I needed to pull down some changes so I actually ran:

git branch --set-upstream redesign-2015 origin/redesign-2015

and the next land worked as expected. Thanks!

On this issue, it would be great to tune the behavior regarding "Author date" vs "Commit date" for git. With our current CI tool, current build and previous build are determined in "Commit date" order not "Author Date', which can result in confusing links.

For example, give these two commits in descending order:

Author date:	2 days ago (11/30/2015 4:23:23 PM)
Commit date:	1 day ago (12/1/2015 9:58:49 AM)
Commit hash:	4df9e5ee76e7d3e0c68872a52a22a2b9bf1bff86


Author date:	1 day ago (12/1/2015 8:31:31 AM)
Commit date:	1 day ago (12/1/2015 8:42:43 AM)
Commit hash:	ad2a15ee14f67c3577a519a6246e1e0db7e99163

4df9e5 would be displayed before to ad2a15 even though it was landed later. It's not really a phab or arc problem, but curious if it would be possible as optional behavior to adjust how the date is determined so that either author date is not used or author date is not preserved in favor of commit date.

This was an intentional change in response to requests by other users in T4333 and elsewhere.

Your use case sounds a bit flimsy to me (the CI tool behavior seems more than a little sketchy?), but wouldn't want to add an option for this even if it was stronger (see T8227 for rationale).

That's sensible to me. Was just an unexpected side effect of improving the arc land workflow for git and thought I'd mention it.

I'll look into ways to address it with the CI tool we're using. Seems like users generally expect commit date ordering there.

epriestley claimed this task.

This has been live for about a month without any major issues cropping up.