Jim,
I've had this reply queued up for a week now. Sorry for the delay.
The problem that I run in to when I work with multiple dependent
changes doesn't seem to be covered by your description.
For me, the trouble with this workflow comes when there is more than
one contributor working on a chain of patches like this one [1]. In
these cases, I find it is particularly dangerous to rebase the whole
chain at once.
Imagine that I'm working on the fourth patch set and another
contributor updates the second one. My work depends on that change
but I now have an older copy of it in my working copy.
Now, if I rebase my out-of-date copy of that change and then upload to
gerrit then it will appear to gerrit to be a replacement for the most
recent version of the change that it has. The work that the other
contributor did is clobbered. I've gotten really good at spotting
this problem because it happens quite often. In these cases, I dive
in and manually tease them apart and ensure that all of the latest
stuff is reflected in all of the changes. I've found it difficult to
teach others about this problem, how to detect when it happens, and
how to properly recover from it.
For this reason, I never rebase more than one patch set at a time. I
also have taken measures to ensure that "git review" will never rebase
my changes, ever. My workflow for rebasing a chain of changes looks
something like the following which I have not taken the time to
automate:
for change in changes_listed_from_least_to_most_dependent:
if change_depends_on_other_change:
parent_version = version_of_parents_latest_patch_set_in_gerrit
git rebase HEAD^ --onto parent_version
git review
Any merge conflict in any of the chain's changes essentially requires
that I rebase the bottom (least dependent) change to master before
doing this. All the contributors to such a chain of changes must be
very careful to work from the most recent version of a change and be
vigilant.
Any thoughts on this?
Carl
[1] https://review.openstack.org/#/q/status:open+topic:bp/bgp-dynamic-routing
On Tue, Feb 2, 2016 at 10:53 AM, James E. Blair <cor...@inaugust.com> wrote:
> Hi,
>
> I'm pleased to announce a new and very simple tool to help with managing
> large patch series with our Gerrit workflow.
>
> In our workflow we often find it necessary to create a series of
> dependent changes in order to make a larger change in manageable chunks,
> or because we have a series of related changes. Because these are part
> of larger efforts, it often seems like they are even more likely to have
> to go through many revisions before they are finally merged. Each step
> along the way reviewers look at the patches in Gerrit and leave
> comments. As a reviewer, I rely heavily on looking at the difference
> between patchsets to see how the series evolves over time.
>
> Occasionally we also find it necessary to re-order the patch series, or
> to include or exclude a particular patch from the series. Of course the
> interactive git rebase command makes this easy -- but in order to use
> it, you need to supply a base upon which to "rebase". A simple choice
> would be to rebase the series on master, however, that creates
> difficulties for reviewers if master has moved on since the series was
> begun. It is very difficult to see any actual intended changes between
> different patch sets when they have different bases which include
> unrelated changes.
>
> The best thing to do to make it easy for reviewers (and yourself as you
> try to follow your own changes) is to keep the same "base" for the
> entire patch series even as you "rebase" it. If you know how long your
> patch series is, you can simply run "git rebase -i HEAD~N" where N is
> the patch series depth. But if you're like me and have trouble with
> numbers other than 0 and 1, then you'll like this new command.
>
> The git-restack command is very simple -- it looks for the most recent
> commit that is both in your current branch history and in the branch it
> was based on. It uses that as the base for an interactive rebase
> command. This means that any time you are editing a patch series, you
> can simply run:
>
> git restack
>
> and you will be placed in an interactive rebase session with all of the
> commits in that patch series staged. Git-restack is somewhat
> branch-aware as well -- it will read a .gitreview file to find the
> remote branch to compare against. If your stack was based on a
> different branch, simply run:
>
> git restack <branchname>
>
> and it will use that branch for comparison instead.
>
> Git-restack is on pypi so you can install it with:
>
> pip install git-restack
>
> The source code is based heavily on git-review and is in Gerrit under
> openstack-infra/git-restack.
>
> https://pypi.python.org/pypi/git-restack/1.0.0
> https://git.openstack.org/cgit/openstack-infra/git-restack
>
> I hope you find this useful,
>
> Jim
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
