[vdsm] git-review
I've recently encountered more and more people not using the git-review tool and manually pushing their changes to Gerrit using raw git commands. Even though there is nothing wrong with doing things the hard way. I prefer not using an overly complicated error prone way to interact with Gerrit. Last I checked the version of git-review in Fedora is broken but I suggest using pip anyway as it is always synced with the master branch. Also, please use topics. Either use a BZ# or a topic codename (eg. live_migration, vdsm_api, nfs4_support) so people can skim the review list for topics they might want to review. Be careful, it automatically uses current the branch name (unless you use -t) so if you giving your branches funny names (I know I do) don't forget to manually specify a topic. More information. http://wiki.openstack.org/GerritWorkflow https://github.com/openstack-ci/git-review ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] git-review submit question
On Thu, May 17, 2012 at 12:46:02PM -0500, Ryan Harper wrote: > I've been using git-review -t branch to submit my patches[1], and > when I need to re-work a patch, I do that locally, and then re-submit > with git-review -t > > In most cases, not all of the patches in the series have been modified > and they contain the same change-id. I assume that since I'm re-basing > to track tip that this ends up having a different git hash and then > re-posts all of the patches (even if they haven't changed). > > The questions are: > > 1) am I doing this in the most efficient way > 2) if not, what should I do differently? I am not aware of a more efficient way. There is a soft skill hiding here: on one hand, an author should be quick to fix issues found in his code. On the other hand, multiple almost-exact revisions are bound to confuse the reviewers. I thus prefer that - An author avoids rebasing untill the review is over (at least one +1). Rebase only if there has been changes in code sections that you are touching. - No bother to Verify your own patch on every re-post. Do it when you feel the review done. - More stable changes are kept at the bottom of the branch. hth, Dan. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
[vdsm] git-review submit question
I've been using git-review -t branch to submit my patches[1], and when I need to re-work a patch, I do that locally, and then re-submit with git-review -t In most cases, not all of the patches in the series have been modified and they contain the same change-id. I assume that since I'm re-basing to track tip that this ends up having a different git hash and then re-posts all of the patches (even if they haven't changed). The questions are: 1) am I doing this in the most efficient way 2) if not, what should I do differently? Thanks, 1. http://gerrit.ovirt.org/#q,status:open+project:vdsm+branch:master+topic:netinfo-speed-fix,n,z -- Ryan Harper Software Engineer; Linux Technology Center IBM Corp., Austin, Tx ry...@us.ibm.com ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
