On Mon, Apr 19, 2010 at 08:24, Ahmon Dancy <
da...@dancysoft.com> wrote:
> Shawn/Simon, I'm confused about your position on topic branches. It was
> always my understanding that if you have, say, two unrelated
> features/bugs/whatever to work on, you do the work for each topic on a
> separate topic branch. But you seem to suggest that this is the wrong way
> to use topic branches.
It depends.
If the changes are touching different files, yes, they probably belong
in different topic branches.
If the changes are touching the same file, but you really can't
predict in what order the maintainer wants to merge them in, then they
belong in different topic branches so they can be worked on
independently more easily. But at some point these have to be merged,
and the merge result has to be tested. And this is where the Gerrit
workflow will require a lot of back-and-forth between the author and
the reviewer, as they work through the merge permutations, test each
merge, review it, and eventually submit it.
If on the other hand there are multiple changes to the same files and
there is a logical progression of those changes, they belong in a
single topic branch. This makes it easier for others to follow along
with the development, and its cleaner to apply that series because the
merge conflicts have already been resolved and dealt with. So
sometimes, yes, you can branch too much or too aggressively in Git,
and just need to fall back to a slightly larger granularity on your
branch.