On Mon, Apr 27, 2015 at 8:20 AM, Olle E. Johansson <[email protected]> wrote:
> > On 24 Apr 2015, at 15:42, Russell Bryant <[email protected]> > wrote: > > On Fri, Apr 24, 2015 at 8:31 AM, Joshua Colp <[email protected]> wrote: > >> Olle E. Johansson wrote: >> >>> Playing around following Matt's wiki page on gerrit usage, I created >>> a team branch and did two commits. When pushing it with "git review >>> {branch}" only the last commit shows up. >>> >>> Is that the way it's supposed to be? I thought the whole branch was >>> the review subject, not just a single commit. >>> >> >> Gerrit works on a single commit (what it refers to as a patch set) that >> you want included into a specific branch. As a result you need to squash >> all commits into a single one, and if review feedback warrants further >> changes they also need to be squashed back into a single commit with the >> original changes. The single commit you post for review is what is reviewed >> and merged into the branch. >> > > Gerrit can also work on a patch series, and tracks dependencies between > those patches. > > > Define "patch series" - how do you commit a series of patches for review? > In some cases, it makes sense for a feature or fix to be proposed as multiple changes in a series. I feel that it makes things easier to review and understand. As a completely realistic example, let's assume we want to add support for toaster control to chan_pjsip. That could be submitted as a series of 3 commits: 1 - ast_toaster: Add core modular API for toaster control. 2 - toastip - Add ast_toaster backend for the toastip protocol. 3 - pjsip_toast - Add chan_pjsip integration with the ast_toaster API. Those *could* all be one commit, but it's really the development of a feature in 3 logical chunks, so breaking it up like this is an alternative. When it comes to what that actually looks like it git. Create a local branch for a feature: $ cd asterisk-git $ git checkout -b example-patch-series origin/master Commit 1: $ echo "some text" > foo $ git add foo $ git commit -m "Add foo" Commit 2: $ echo "some more text" >> foo $ git commit -a -m "Add more text to foo" We now have 2 commits on top of the master branch: $ git log --oneline origin/master..HEAD 5a53b4f Add more text to foo. 4bf86fa Add foo. Post series of 2 commits for review: $ git review You are about to submit multiple commits. This is expected if you are submitting a commit that is dependent on one or more in-review commits. Otherwise you should consider squashing your changes into one commit before submitting. The outstanding commits are: 5a53b4f (HEAD, example-patch-series) Add more text to foo. 4bf86fa Add foo. Do you really want to submit the above commits? Type 'yes' to confirm, other to cancel: (You would type 'yes' here because you're submitting 2 changes for review intentionally.) Here's a wiki page that I think does a nice job laying out some reasoning behind best practices for breaking up changes into a series of commits if anyone is interested: https://wiki.openstack.org/wiki/GitCommitMessages -- Russell Bryant
-- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
