Our team is using phabricator to review code. In eclipse, we can post a review request by added Auditors: someone in comment when check in repository. Is there a command patch in comment to update the review request?
arc uses information about the working copy (like the path, branch name, local commit hashes, and local tree hashes, depending on which version control system you are using) to figure out whether you intend to create or update a revision. If it guesses incorrectly, you can force it to either create or update a revision with:
$ arc diff --update <revision>
see http://www.phabricator.com/docs/phabricator/article/Arcanist_User_Guide_arc_diff.html
Use Arcanist, command arc diff and arc update
Related
I download code from Gitlab, then create a new branch, update some files and create a review. Then I add a file, execute arc diff --allow-untracked, it reports Usage Exception: There are several revisions which match the working copy:. I execute arc diff --allow-untracked --update D75 to update the existing review, but it creates a new review.
Linting...
No lint engine configured for this project.
Running unit tests...
No unit test engine is configured for this project.
SKIP STAGING No staging area is configured for this repository.
Updating commit message...
Created a new Differential revision:
Revision URI: http://codereview.domain.com/D76
I try many times but it always creates a new revision. How to use arc diff --update?
You shouldn't need --update but you do need to specify the base of your change, so to update the revision associated with the current HEAD, try the following:
arc diffHEAD^
If you've got two commits then you need to use HEAD^^.
To update everything on the current branch:
arc diffparent-branch
So assuming your current branch was branched from master:
arc diffmaster
The arcanist documentation covers this topic in detail, so for a more complete understanding of how arc diff decides which commits to submit, read Arcanist User Guide: Commit Ranges.
we are using Phabricator to performs pre-commit reviews & audits on a mercurial repo. Phabricator does not host the repo, it only observes it.
The project was configured with auto-close, so until recently, pushing all commits of a validated review on the repository automatically closed the related revision.
So far so good.
Today, our admin found out that a php lib was missing and installed it. It seems the deamon never work 'correctly' until now. However, from this moment, all existing reviews have been updated in a way that the very first commit of the review is the only one that can be seen. Any new review is fine until it is closed, where Phabricator writes:
Closed by commit R1:a9a9e1153022: doc: update changelog (authored by vsiles). ยท Explain WhyThu, Sep 7, 5:09 PM
This revision was automatically updated to reflect the committed changes.
(were a9a9e1153022 is the revision of the very first commit, but that's was always the case iirc). Now the whole review only shows the first commit, not all of them.
If we go to the 'History' tab in the review, we can see that Phabricator added an additional 'Diff' with the revision & timestamp of the first commit, after all the diff we pushed. This seems to be the problem. If we modify the history to show all commits but this one, we find back all our review content.
For the moment, my only work-around is to remove the 'auto-close' feature, and close reviews by hand using arc close-revision DXX. There is no more automatic step by Phabricator that messes things up, and the additional diff is not generated by Phabricator.
Can someone explains why Phabricator considers that the review is closed by the first commit, which seems to be the issue here ?
The recommended workflow for Phabricator is to use arc land to push and close the revision. Pushing using mercurial directly may not have the desired outcome because mercurial has no knowledge of Differential revisions, and Phabricator daemons are left to try to reconstruct what they can of the links between revisions and commits after the fact.
I made a diff in Phabricator containing a config file with sensitive information. Usually I would be content with abandoning the diff, but I don't want anybody seeing my password (even after I change it)
I should have been more careful when making my commit but it has already been done.
Take a look at the ./bin/remove command:
NAME
remove - remove objects
SYNOPSIS
remove command [options]
Administrative tool for destroying objects permanently.
WORKFLOWS
destroy [options] object ...
Permanently destroy objects.
help [command]
Show this help, or workflow help for command.
log
Show a log of permanently destroyed objects.
Use help command for a detailed command reference.
Use --show-standard-options to show additional options.
I want my team including myself to review commits of each other. None of commits should be pushed including mine into repo until it's not audited by other team member. I kind of lost in phabricator documentation, so i'm asking here, is there any way to setup that kind of workflow?
You can only restrict pushes to repositories hosted by Phabricator. If your repository is hosted elsewhere (like GitHub), Phabricator obviously can't prevent users from pushing to it.
To restrict pushes, create a new Herald rule (in the Herald application), like this:
Create a new "Commit Hook: Commit Content" rule.
Select "Global" as the rule type.
Then configure the rule like this:
When [all of] these conditions are met:
[Accepted Differential revision][does not exist]
Take these actions every time this rule matches:
[Block change with message][Review is required for all changes.]
You may want to use additional conditions like this, to run the rule only in certain repositories:
[Repository][is any of][ ... list of review-requied repositories ... ]
Or a condition like this, to let users bypass the rule by writing some string like "#bypass-review" in a message in an emergency:
[Body][does not contain][#bypass-review]
If you add a bypass like this, you can mention it in the rejection message.
It seems that you want a Pre-Commit Code Review. We set this up by doing the following (we use Git repos. If you use some other type, these steps may be different):
Setup a Herald rule
New rule for: Commit Hook: Commit Content
If you only want one repo, you can use Rule Type: Object, however, we used Global
For the conditions: we selected Accepted Differential revision and does not exist
Action: Block Change with message For the message, we refer them to an article that walks them through using Arcanist
Each project will need a .arcconfig with at least this line:
{
"phabricator.uri": "http://your.phabricator.url"
}
Day-day developers are going to have to use arcanist.
Developer creates a local branch.
Changes and commits code to the local branch.
When finished, run arc diff [base_branch_name]
This will create a Differential revision that will allow another developer to code review.
If changes are needed, the developer checks out his local branch, makes changes, makes commits, and re-runs arc diff [base_branch_name] to update the diff.
After all revisions are done, run arc land [local_branch_name] --onto [base_branch_name]
I hope this helps. Also, Phabricator developers hangout in freenode.net IRC channel called #phabricator. Come join the community; they have always been very helpful for me.
After reading the builtin help, it seems to me that both commads can be used for modifying the workspace to match a certain revision. But I don't understand the differences between update and checkout. Please include some trivial workflows in your answer which show when update/checkout are appropriate.
First major difference is that if you have a remote url set, update will pull first latest artifacts from the remote repository.
Another difference is that if you have uncomitted changes, checkout will not run (unless you force it), whereas update will retain your changes and reapply them. With update you can therefore integrate changes from other users before committing.
So:
Update is what you need when you collaborate on a project, in order to prevent forks.
Checkout lets you deploy a particular version.