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'
redesign-2015@{upstream}
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

and

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.