Close Revision on squash merge


#1

We recently started to use Phabricator for Code Reviews and Repository tracking. Today we had the first time were we merged feature branches on a repository master branch and I had to discover that autoclosing of revisions did not work as we hoped.

I think I should first explain our workflow. We normally get tasks from our customers which then will be worked on by the assigned developer. For each task a developer creates a new feature branch from master. On the feature branch developers commit until they finished the task, they push their branch for testing and create a revision with arc diff. So far this all works very well.
Once the revision is reviewed we accept it and let the customer know the ticket has been finished. They do their own visual and functional review and if they are happy we will be ready to land it on master. This is then done by the specific project owner with a squash merge in git. I was initially under the impression phabricator was matching revisions and commits based on their changeset, but this seems not to be the case.
The squash commit was not associated with the accepted revision and also didn’t close it.

How can we get Phabricator to close the accepted revisions? I found that commits with closes D1 should close the revision D1 but this would mean the project owner would have to check in Phabricator for the correct revision each time he merges a branch, which isn’t any faster than closing the revision manually.

All repositories are set to only autoclose on master and arc history.immutable is set to true. We also set differential.always-allow-close to true.


#2

You should use arc land --squash to land the changes. --squash is needed to explicitly bypass the history.immutable flag you have set to true.


#3

I tried to land a feature branch with arc land --squash today and ran into a few issues. By default, it doesn’t allow me to edit the commit message and directly pushes the commit to master. Since we mostly have to alter the commit message I used arc land --squash --hold and then amended the commit to alter its message. This way I still had the problem that the created commit was not on any branch and I had to cherry-pick it onto master. Why is it that arc doesn’t apply the squash commits to the local master and pushes it to the remote branch directly. This workflow is quite cumbersome at the moment, what can we do to make it less complicated? Is there any way that squash commits get applied to local master instead of being dangling?


#4

Why is it that arc doesn’t apply the squash commits to the local master and pushes it to the remote branch directly.

This behavior allows arc land to work even if the local master is ahead of the remote master, or neither the local master and remote master can fast forward to one another, or doesn’t exist, or tracks a master in a different remote, or tracks some remote branch other than master.

This workflow is quite cumbersome at the moment, what can we do to make it less complicated?

Go back in time and convince everyone who uses git to never do any of those things, or if they insist on doing those things don’t complain to the upstream that they break arc land.

This way I still had the problem that the created commit was not on any branch and I had to cherry-pick it onto master.

Why do you need to cherry-pick the change onto your local master before pushing it?


#5

Well I also could push it to the remote master as arc suggests, but in the end it results in the same situation. We usually have a set of branches which are scheduled for merging, so I have to run one more command before I can continue with the next branch. If there was an arc land --edit option where I can edit the message before the commit is created, I wouldn’t mind it being pushed directly.


#6

so I have to run one more command before I can continue with the next branch.

Why do you have to run additional commands before you can continue with the next branch?


#7

Our previous flow:

git merge --squash feature/branch
git commit
....
git push #everything

With arc:

arc land --squash --hold feature/branch
git commit --amend 
git push origin master:commit-hash
....

This adds one step for each merge or am I missing something?


#8

Ah, sure. If you don’t push after each merge, you need to run more commands.


#9

Why do you need to alter the commit message?

Your workflow sounds like it has a lot of manual steps that should be mechanized. Is the person doing all the merge/push an engineer or a product person?

This is a good example of a “fishing expedition” ticket. The workflow that got you in this point is a lot more complex than you first described, and we still don’t have a full picture of what’s going on. Your workflow is not something that we have ever met, and in order to actually figure out how to help you we need a long string of questions. This is not a good investment of our time, compared to building more code, because building code helps more people in the same amount of time.

Please see https://secure.phabricator.com/book/phabcontrib/article/describing_problems/ and the articles leading from it, to figure out how to provide us all the information we actually need to be able to help you.