4 ms·

OP here. Apologies for not being clear. This is very similar to how Gerrit works. There's an additional stage before the commit lands on the trunk (where commit

OP here. Apologies for not being clear. This is very similar to how Gerrit works. There's an additional stage before the commit lands on the trunk (where commits get reviewed). You rework your commit by amending/interactive rebasing and pushing again. When you get approval, you can submit your commits and Gerrit will try to merge them (even if the trunk has moved; you can say it's sort of cherry-picking on the trunk). If it can't merge the commit, you'll have to take a pull and push your commit again by resolving conflicts. Edit: Tweaked the post a little to make it more clear.

blintz 7y ago
So the ‘additional stage’ works exactly like a branch then, right?
- Jach 7y ago
  Except without all the benefits of having real branches that might be desirable. To me OP's flow just reminds me of a particular way of doing development with perforce. You make your changes against one branch everyone works from, move them to a new 'pending changelist', then send the diff to another system for review. (You might even use perforce's own swarm tool by making a 'shelf' of your pending changes and starting a review from that.) Rework is done, you send over the new diff/overwrite the shelf, reviewers can see diff-of-diffs (tracked only by the review tool) and overall-diff. Eventually if all is well (or if your review has been in limbo and no one's going to argue if you merge without review anyway) you commit the pending changelist. (Which might involve in reality sending your diff again to another service, and that service tries to integrate and build/run tests using a new changelist in your name and only finalizing a commit to the master branch with that.) I wouldn't recommend it. Not that I think the popular pull request model is much better, but at least you have options, though that's more to do with using a DVCS. I'd like to sometime try Fossil with a team, which aims to have the technical benefits of DVCS but with the tradeoff of cathedral vs bazaar being given back to the cathedral style, which is what I see pull requests as popularly done on github as clumsily trying to accomplish.
anticristi 7y ago
If I understand your post correctly, I agree with its substance: keep unreviewed changes small, probably a subclass of Kanban's "reduce WIP". This should be already known industry-wide. The Kubernetes Contributor guide states: "break large changes into a logical series of smaller patches which individually make easily understandable changes, and in aggregate solve a broader issue". However, I feel that your technological choice is a bit nitpicking. I believe that creating an alias for 'git checkout master; git pull; git checkout my-branch' and another alias for 'git push; curl .../review' would essentially implement the same workflow as you suggest. (Granted, in some organizations, creating a branch is a heavy process: It requires opening a JIRA ticket, the branch needs to be well-named, etc. but these are not technological issues.)
Aqueous 7y ago
It's quite possible to follow this or a similar workflow with merge / pull requests. In fact, this describes pretty closely what I do. I work off master, amending a single commit, periodically squashing or fixing up newer commits, and periodically rebasing. Then when I'm ready to deploy I push my local master to a remote staging branch (git push origin master:some_new_remote_branch_issue_xxxxx) and open a MR on Gitlab. Then, when the MR gets merged and deployed, I rebase my local master against remote master and my commit gets "eaten", thus putting me back on a clean master branch. I never leave master locally. Rinse, repeat. How is this different from what you are suggesting?

blintz 7y ago

So the ‘additional stage’ works exactly like a branch then, right?

Jach 7y ago
Except without all the benefits of having real branches that might be desirable. To me OP's flow just reminds me of a particular way of doing development with perforce. You make your changes against one branch everyone works from, move them to a new 'pending changelist', then send the diff to another system for review. (You might even use perforce's own swarm tool by making a 'shelf' of your pending changes and starting a review from that.) Rework is done, you send over the new diff/overwrite the shelf, reviewers can see diff-of-diffs (tracked only by the review tool) and overall-diff. Eventually if all is well (or if your review has been in limbo and no one's going to argue if you merge without review anyway) you commit the pending changelist. (Which might involve in reality sending your diff again to another service, and that service tries to integrate and build/run tests using a new changelist in your name and only finalizing a commit to the master branch with that.) I wouldn't recommend it. Not that I think the popular pull request model is much better, but at least you have options, though that's more to do with using a DVCS. I'd like to sometime try Fossil with a team, which aims to have the technical benefits of DVCS but with the tradeoff of cathedral vs bazaar being given back to the cathedral style, which is what I see pull requests as popularly done on github as clumsily trying to accomplish.

anticristi 7y ago

If I understand your post correctly, I agree with its substance: keep unreviewed changes small, probably a subclass of Kanban's "reduce WIP". This should be already known industry-wide. The Kubernetes Contributor guide states: "break large changes into a logical series of smaller patches which individually make easily understandable changes, and in aggregate solve a broader issue". However, I feel that your technological choice is a bit nitpicking. I believe that creating an alias for 'git checkout master; git pull; git checkout my-branch' and another alias for 'git push; curl .../review' would essentially implement the same workflow as you suggest. (Granted, in some organizations, creating a branch is a heavy process: It requires opening a JIRA ticket, the branch needs to be well-named, etc. but these are not technological issues.)

Aqueous 7y ago

It's quite possible to follow this or a similar workflow with merge / pull requests. In fact, this describes pretty closely what I do. I work off master, amending a single commit, periodically squashing or fixing up newer commits, and periodically rebasing. Then when I'm ready to deploy I push my local master to a remote staging branch (git push origin master:some_new_remote_branch_issue_xxxxx) and open a MR on Gitlab. Then, when the MR gets merged and deployed, I rebase my local master against remote master and my commit gets "eaten", thus putting me back on a clean master branch. I never leave master locally. Rinse, repeat. How is this different from what you are suggesting?