Re: Rietveld workflow problems

[Janek Warchoł]

2011/9/21 David Kastrup <address@hidden>:
> Reinhold Kainhofer <address@hidden> writes:
>
>> Am Wednesday, 21. September 2011, 12:45:17 schrieb David Kastrup:
>>> Because it doesn't make sense to combine unrelated patches in that
>>> manner.  You can't find them in the history then, and if the large patch
>>> gets applied or reverted, the independent small patch has to go along.
>>
>> To submit a review to rietveld, the changes do not necessarily have to
>> be in one single patch. If you do "git cl upload origin/master", all
>> patches in your local branch will be submitted as one merged
>> review.
>
> Sure.  But there is no point in letting people review unrelated work
> that has been merged into the total review.

>From what i understand, this "unrelated, but somehow related" work
consists of small patches about infrastructure.  If they are small, i
see no problem in including them in the "main" review.

>> When pushing to git, you can still have multiple patches.
>
> Even in the case where the patches are related by more than dependency,
> it might make sense to be able to review several parts separately.
> Increases the amount of work one can keep track of before eyes start
> glazing over.

My impression is that using separate branches for development, as
suggested by Graham not long ago, would help solving the problems you
encounter: all "related" (depending on themselves) commits would be on
a dedicated branch, so you can tell people "checkout this branch to
see how it works", and still a review could be made without including
some commits.  Example:
create new branch
make some "small fixes to infrastructure"
commit them, let's say the committish is aaabbbc(...)
make "the big change which depends on aaabbbc(...)"
commit it
create a review of big change without those small fixes: 'git cl
upload aaabbbc(...)'. in review's description, write "pull from branch
xyz to get this feature".

Seems straightforward to me.

cheers,
Janek