3 ms·
I've used both, and I wouldn't describe the time savings as significant. Compare the case study of Yang, who runs either git checkout neighbour-fix gi
by strken 6y ago
I've used both, and I wouldn't describe the time savings as significant.
Compare the case study of Yang, who runs either
git checkout neighbour-fix
git checkout -b yang-work
<time passes>
git checkout neighbour-fix
git pull
git checkout yang-work
git rebase neighbour-fix
or
arc patch --diff D12345 # arc's a CLI tool for Phabricator
<time passes>
git fetch
git rebase -i HEAD~2
<goes into phabricator and finds the new commit hash for D12345>
<pastes it into vim in place of the original commit hash>
From this, it's not clear to me that Yang is getting the better deal if he uses Phabricator. Certainly, he has to enter fewer commands, but he also has to leave the terminal to go copy a commit hash from Phabricator, and then paste it into an interactive rebase session. If given the choice, I'd choose the PR workflow over the Phabricator workflow, based on not switching to the browser and not needing to copy-paste things into an interactive rebase. Phabricator and arc handle deep stacks of diffs more nicely, but that's rare enough that I'd rather optimise for the common case.
Apologies if I've misunderstood exactly which commands Yang would run in either case.
- sjburt 6y agoAfter <time passes>, you can run arc patch --diff D12345 again and arc creates another branch called arc-diff-d12345-1 or something like that, then you can rebase -i onto that. I feel like phab had a couple workflows that were very efficient and if you ever had to do multiple git operations you were probably using it wrong. You could do everything but the actual code review in the CLI. Github is hampered because they can only use git operations and they just try to figure everything out server-side. That said, phab certainly has it's idiosyncrasies and anything outside of the workflow that they intended was not supported.