Urs Liska <u...@openlilylib.org> writes: > Am 20.12.2013 11:12, schrieb David Kastrup: >> As the typical victims for pushers are often able to grant push access, >> you'll probably not have to go through this very often before they beg >> you to accept push access. > > I think I will do that soon. > Some time in the past I would have considered it a hassle not to have > push access. > But now I'm feeling it's quite good to go through the review process > for a few times before having push access :-) > >> >>> >Or should I leave the branch open, create the patch set and send it to >>> >-devel? >> After rebasing on current master, that's doable, too. Again, if you >> think that not all stages will necessarily compile, state that you want >> this done as a merge commit. >> > > Just as an opinion: Would you restrict this to be _compilable_ or > should this also go for commits that aren't _useful_. > > If I have more thorough rewrite of a page of the website (as the > current "Features" patch), I will have a number of commits > (e.g. "reorder items", "update section XX", "update section YY"). > Although not having tested I assume the website is compilable after > each of the commits, but these states don't make much sense.
"Useful" does not matter much: the main idea is that the "main line" remains useful for finding problems with "git bisect". A branch is always a bit of a hassle, so it should be reserved for a connected set of changes. For example, I tend to leave out Documentation and regtests from such short-circuit branches. "Update section XX" and "update section YY" usually can be done in a single commit: after all they went through a connected review, and the changes are logically connected without being physically intertwined. > Would you suggest to put such a series in a separate "thread" (by a > merge no-ff) or not. Usually not. But some of that might be pulled into a single commit. > In my own work I would always do such stuff the no-ff merge commit > way. -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
