2011/9/21 David Kastrup <[email protected]>: > Reinhold Kainhofer <[email protected]> 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 _______________________________________________ lilypond-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-devel
