Open Stack

On 03/01/2013 10:43 AM, Ilya Persky wrote:
> Hi Guys! 
> 
> Consider the following situation: we registered a blueprint
> (my-blueprint) which requires a lot of coding. Say this blueprint
> describes a way for creating unit tests for some big part of code.
> It is generally a good practice not to include all this code in a huge
> commit which can become a cause of multiple conflicts and reviewers'
> headache, but to break it into a series of small independent commits (in
> our example: consistent subsets of unit tests for independent modules e.g.).
> 
> My question is: what is the right way to publish such series of commits?
> 
> Say, I created a topic "bp/my-blueprint" which points to last upstream
> commit and then I made three commits:
> 
> upstream_HEAD -> bp_commit_A -> bp_commit_B -> bp_commit_C
> 
> Is this a good practice to execute "git review" for each of these
> commits? I see a lot of problems here: bp_commit_B can't be merged until
> bp_commit_A is merged, etc. Or I'll have to rebase all of them somehow.
> 
> Another way is to create multiple topic branches for each of the commits:
> 
> bp/my-blueprint1: upstream_HEAD -> bp_commit_A
> bp/my-blueprint2: upstream_HEAD -> bp_commit_B
> bp/my-blueprint3: upstream_HEAD -> bp_commit_C
> 
> This doesn't look pretty and I don't know then what is the right way to
> name such topics.
> 
> What do you think?..

Just run "git review" a single time with your tree set up like your
first example.  It will upload all three changes and will keep track of
the fact that C depends on B which depends on A.  It will ensure that
they can only be merged in order.

-- 
Russell Bryant