Page MenuHomePhabricator

Arc land fails: no commits on <feature-branch> which are not already present on target
Closed, InvalidPublic

Description

I cross-posted on stackoverflow -- http://stackoverflow.com/questions/39757352/arc-land-fails-no-commits-on-feature-branch-which-are-not-already-present-on

More or less, I created this scenario on purpose:

Steps
# We use git-flow.
$ git flow feature start <feature>

# update a file
$ git commit <file> -m '<message>'
$ git rebase -i develop
$ git push -u origin <feature-branch>

# Try arcanist now
$ arc diff

# diff was accepted
$ git flow feature finish <feature>

# feature branch removed, now in develop, let's push
$ git push

So now I'm in a state where the branch is gone, and I cannot arc land due to the local branch being unavailable. NOTE: git (and gitolite) works just fine

$ arc land

Exception
Branch "<feature-branch>" does not exist in the local working copy.

/rant.. I don't see my feature branch in Phabricator's Maniphest. Why not?

I can pull that branch back:

$ git fetch -a
$ git checkout <feature-branch>

But I am still unable to land:

$ arc land
Landing current branch '<feature-branch>'.
TARGET  Landing onto "<feature-branch>", 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/<feature-branch>...

Usage Exception: There are no commits on "<feature-branch>" which are not already present on the target.

And as far as I can tell, I have no recourse for closing that diff. How do I recover?

Event Timeline

This isn't a bug -- I think we've just set you up with the wrong expectations somehow. There's probably some sort of documentation we can improve to make it more clear what arc land does, and maybe I can figure out how where we led you astray by asking some questions:

  • What do you expect arc land to do, exactly?
  • Why do you believe it will do that (e.g., did you read a particular piece of documentation that led you to this expectation)?

Thanks for responding, Evan.

So my expectation, coming from a gitflow/github-style workflow, is that I can generally use the same work flow with phabricator. I say generally, because my expectation is that I can consume phabricator where I want to. That is to say, I vastly prefer to use git commands and not a replacement (e.g. arc land vs git commit/merge/rebase). However, where git doesn't have a command set (e.g. arc diff to setup a review), I'm okay with using the tool for that job.

In the case above, I think something resolved the issue on the backend (maybe there's a a cron-type job which does a cleanup?). I didn't have to manually close. My branch also showed up later and so I'm guessing this was more of a sync issue between the frontend and backend (gitolite) than anything else. Is there a command to force the sync 'now'? Self repair is nice, but I'd like to know my commits are finished and I can move on immediately.

My expectation for arc land is that the command would finalize/finish and/or force the sync if all the pieces are already in place.

Additionally, coming to phabricator, my expectation is that arcanist would handle the front-end (i.e. phabricator), but not strong-arming my local development environment. I know at least in part, arc provides nice convenience. And that shouldn't be discounted. But my expectation is that arc is the tool that knows how to handle phabricator first and convenience is second. In my exploring example above, what I found was that arcanist is more convenience for my local environment and less with phabricator.

I hope that helps explain my viewpoint better.

What led you to arc land, specifically?

For example, why did you try to run arc land instead of (for example) arc close-revision or no command at all (which is what it sounds like you actually wanted)?

I was attempting to follow what I understand as the (abbreviated) standard process for a review:

  1. make changes in a branch
  2. create a review for that branch: arc diff
  3. After review sign-off, then finalize with arc land

This is mostly outlined here (which I understand is your preferred workflow): https://secure.phabricator.com/w/guides/arcanist_workflows/

That document says:

To push a change, I use arc land:

Is that unclear? How could we make it more clear that arc land replaces git push in this workflow?

Additionally, coming to phabricator, my expectation is that arcanist would handle the front-end (i.e. phabricator), but not strong-arming my local development environment.

This expectation is also generally not correct, especially for arc land -- is there documentation that sets up this expectation?

Here's, e.g., an excerpt of the arc help land text:

This command merges and pushes changes associated with an accepted
revision that are currently sitting in ref, which is usually the
name of a local branch. Without ref, the current working copy
state will be used.

Does that suggest that arc land does not mutate the working copy? Could it be more clear?

I think you've already mentioned the right answer for my initial question (though I'm not in a state to try it out just yet): arc close-revision. But that's not obvious as an alternative to closing out a diff.

The documentation for arc land is clear, but it is incomplete: Doesn't arc land do more than a simple git push? I know diffs are closed; that makes me believe that arc land also runs arc close-revision. I didn't see an obvious alternative workflow for arcanist other than the one I mentioned above: code changes > arc diff > arc land.

"As someone new to phabricator, and already having a preferred workflow, I'd like to know how to mentally map my current workflow with phabricator's toolset."

Since it doesn't seem like the documentation is incorrect anywhere, this doesn't appear to describe a bug in Phabricator which we can accept upstream. See Support Resources and Contributing Bug Reports for details on what we do and do not provide support for.

I'm disappointed by this response.

I'm sorry you feel that way. These kinds of requests are frustrating for us too, which is why we try to make it clear upfront in the documentation that this is not an appropriate forum for them.