4 ms·

Can you describe your stacked workflow with phabricator? I have tried to impose the LKML/straight-line-rebase workflow on my teams when I can, but problems with

Can you describe your stacked workflow with phabricator? I have tried to impose the LKML/straight-line-rebase workflow on my teams when I can, but problems with Phabricator _always_ crop up, and it's difficult to onboard people. The default phabricator workflow really likes to squash many commits into a single diff. How do you go about preparing a "stack" of changes, prepare one diff for each git commit, and then apply changes on top of each one as review comments come in? I've ghetto-rigged my own scripts to generate stacked diffs, checking out a new branch for each one, but it's fragile, and not really suitable for sharing with all new team members. I have not found a magic arcanist incantation to generate a changelist based on multiple commits.

iggldiggl 7y ago
> The default phabricator workflow really like to squash many commits into a single diff. That problem also noticeably cropped up when Mozilla switched to Phabricator for its reviews, and the end result was/is that there's now an official helper script for submitting commit stacks without squashing ("moz-phab"). Because that took a little while to develop after Phabricator became mandatory, though (and also because installing arcanist with all its required dependencies can apparently be somewhat of a pain, plus because arcanist has some further foibles like insisting to actually check out each revision you want to submit, which then subsequently can lead to needless recompiling), some people wrote their own solutions, which a) were ready earlier than the official solution and b) allow you to avoid installing arcanist at all: - "Phlay" for Git (https://github.com/mystor/phlay https://github.com/mystor/phlay) - Mercurial already has the "phabsend" extension, which was then forked and extended and currently lives at https://bitbucket.org/KwanEsq/phabsend-moz/src/default/ https://bitbucket.org/KwanEsq/phabsend-moz/src/default/, though I think some changes might have actually made their way back into the original phabsend extension distributed with Mercurial (one problem with the official extensions as of a while ago was that it used a Phabricator API that didn't work for binary files - I think this has been fixed in the fork, but not yet in the official extension included directly with Mercurial). (Also I think that there's currently work underway to make "moz-phab" work without a local arcanist installation, too). So the takeaway from this is that there is indeed no good official solution for this, but "phabsend" or "phlay" might be a better starting point.
- isopede 7y ago
  Thanks. I really want to wanted to like Phabricator, but every interaction with arcanist just feels like hitting the "I'm feeling lucky" button. It completely violates the principle of least surprise. To me, at least. My new team is using Github. Can Github be wrangled to enforce a rebase-on-merge workflow with PRs? I am committed to keeping the "one commit per idea" mantra, but I don't see any way in Github to enforce "no-merge commits." Does Github keep track of comments across PRs if they are rebased? I don't want to see extra commits on top of PRs that consist of things like "address reviewer A's comments," but I do want the comments tracked on Github. Is this possible?
  - lima 7y ago
    You can enforce squash commits and it can track commits. What it can't do is automatically rebase dependent revisions.
lima 7y ago
What you want to do is to submit one revision per commit, and link them together via dependencies (the experimental branch of arcanist does this automatically). Having individual revisions is one of the main advantages of this workflow. You then set your .arcrc base to git:HEAD^ and have one local branch per stack, submitting each via arc diff. There a 1:1 mapping between revisions and commits, which makes things a LOT easier, especially rebases. You can then use an interactive rebase to re-visit and amend old revisions, or land them. I also have an autodiff alias in .arcrc that will automatically create a new revision and open it in the browser, assuming the Test Plan field is already filled out in the commit: "autodiff": [ "diff", "--allow-untracked", "--verbatim", "--browse" ] And useful .bashrc aliases for working with a stack: alias cascade-show="git log @{push}..HEAD --oneline" alias cascade-amend="git rebase @{push} -x 'arc amend'" alias cascade-rebase="git rebase -i @{push}" alias cascade-autorebase="git rebase -i @{push} -x 'arc diff HEAD^ -m Autorebase'"

iggldiggl 7y ago

> The default phabricator workflow really like to squash many commits into a single diff. That problem also noticeably cropped up when Mozilla switched to Phabricator for its reviews, and the end result was/is that there's now an official helper script for submitting commit stacks without squashing ("moz-phab"). Because that took a little while to develop after Phabricator became mandatory, though (and also because installing arcanist with all its required dependencies can apparently be somewhat of a pain, plus because arcanist has some further foibles like insisting to actually check out each revision you want to submit, which then subsequently can lead to needless recompiling), some people wrote their own solutions, which a) were ready earlier than the official solution and b) allow you to avoid installing arcanist at all: - "Phlay" for Git (https://github.com/mystor/phlay https://github.com/mystor/phlay) - Mercurial already has the "phabsend" extension, which was then forked and extended and currently lives at https://bitbucket.org/KwanEsq/phabsend-moz/src/default/ https://bitbucket.org/KwanEsq/phabsend-moz/src/default/, though I think some changes might have actually made their way back into the original phabsend extension distributed with Mercurial (one problem with the official extensions as of a while ago was that it used a Phabricator API that didn't work for binary files - I think this has been fixed in the fork, but not yet in the official extension included directly with Mercurial). (Also I think that there's currently work underway to make "moz-phab" work without a local arcanist installation, too). So the takeaway from this is that there is indeed no good official solution for this, but "phabsend" or "phlay" might be a better starting point.

isopede 7y ago
Thanks. I really want to wanted to like Phabricator, but every interaction with arcanist just feels like hitting the "I'm feeling lucky" button. It completely violates the principle of least surprise. To me, at least. My new team is using Github. Can Github be wrangled to enforce a rebase-on-merge workflow with PRs? I am committed to keeping the "one commit per idea" mantra, but I don't see any way in Github to enforce "no-merge commits." Does Github keep track of comments across PRs if they are rebased? I don't want to see extra commits on top of PRs that consist of things like "address reviewer A's comments," but I do want the comments tracked on Github. Is this possible?
- lima 7y ago
  You can enforce squash commits and it can track commits. What it can't do is automatically rebase dependent revisions.

lima 7y ago

What you want to do is to submit one revision per commit, and link them together via dependencies (the experimental branch of arcanist does this automatically). Having individual revisions is one of the main advantages of this workflow. You then set your .arcrc base to git:HEAD^ and have one local branch per stack, submitting each via arc diff. There a 1:1 mapping between revisions and commits, which makes things a LOT easier, especially rebases. You can then use an interactive rebase to re-visit and amend old revisions, or land them. I also have an autodiff alias in .arcrc that will automatically create a new revision and open it in the browser, assuming the Test Plan field is already filled out in the commit: "autodiff": [ "diff", "--allow-untracked", "--verbatim", "--browse" ] And useful .bashrc aliases for working with a stack: alias cascade-show="git log @{push}..HEAD --oneline" alias cascade-amend="git rebase @{push} -x 'arc amend'" alias cascade-rebase="git rebase -i @{push}" alias cascade-autorebase="git rebase -i @{push} -x 'arc diff HEAD^ -m Autorebase'"