Personally (this is completely anecdotal, and not backed by any serious data), I have found it drives people to do multiple small commits, as they rebase a lot easier.
using something like git review means that the entire chain is rebased by default when you summit a new patch on top, and I have the `git commit --am -a --no-edit && git fetch && git rebase` in muscle memory at this point.
(the lack of ability to have PRs based off other open PRs is one of the biggest issues I have with the current github / pull request model, so I probably over compensate for that type of situation)
How does Gerrit handle a group of commits in a branch? That it, if a feature takes several commits to implement and some of them depend on changes made in earlier commits in the branch, how do you ensure that the earlier commit is approved and applied to the main branch before the later commit?
it groups the branch into a chain of commits, and has dependancies between them, so you can approve a commit on top of the chain, but it will not merge until the ones it is based off merge.
My recollection was that you had to give each commit its own local branch name and both rebase and push them one-at-a-time with Gerrit. Are you saying that an entire branch of commits can be pushed and updated at one time?
yeah - at least with something like git-review [1] when you do git review on a branch with multiple commits, it creates a chain of commits in gerrit with one command.
Can you be more specific about the failure mode here? If we have a series master -> A_review -> B_review, and B_review is targeted to A_review in the PR tool, then a fast-forwarding merge of A_review to master just advances the master branch name and automatically updates B_review to now target master. No merge commits take place.
Personally (this is completely anecdotal, and not backed by any serious data), I have found it drives people to do multiple small commits, as they rebase a lot easier.
using something like git review means that the entire chain is rebased by default when you summit a new patch on top, and I have the `git commit --am -a --no-edit && git fetch && git rebase` in muscle memory at this point.
(the lack of ability to have PRs based off other open PRs is one of the biggest issues I have with the current github / pull request model, so I probably over compensate for that type of situation)