Urs Liska <u...@openlilylib.org> writes: > Am 20.12.2013 10:45, schrieb Trevor Daniels: >>> 3) >>> >What to do if my branch contains more than one commit? >>> >Should I squash them so the patch is one (big) commit? I wouldn't like >>> >that, for example because I would separate commits that move stuff (e.g. >>> >to other website nodes) from commits that change text (so translators >>> >have easier work)? >> No, leave them as separate commits and merge them into staging. >> > > OK, I've understood all your comments except this one. > Should I merge to staging and _then_ create the git format-patch from there?
Actually, I don't think that "git format-patch" does merge commits. If you arrived at a stage where you can create sensible merge commits yourself, it's probably less painful to just ask for commit access. Until that time, you rebase on origin/master (!) and send the series of commits including your desired merge points if any to the unlucky pusher. Rebasing on master rather than staging makes sure that if staging is thrown away, your patches will still be ok. Of course, this does not work if master _does_ progress and causes merge conflicts in the patches, but that's then the trouble of the pusher. 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. > 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. -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
