[prev in list] [next in list] [prev in thread] [next in thread] 

List:       vdsm-devel
Subject:    [vdsm] git-review submit question
From:       danken () redhat ! com (Dan Kenigsberg)
Date:       2012-05-18 20:30:53
Message-ID: 20120518203052.GE31947 () redhat ! com
[Download RAW message or body]

On Thu, May 17, 2012 at 12:46:02PM -0500, Ryan Harper wrote:
> I've been using git-review -t <topic> 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 <same topic branch>
> 
> 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.

[prev in list] [next in list] [prev in thread] [next in thread]