lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Issue 3718 in lilypond: Patch: Web: Reword contactUsAbout macro


From: David Kastrup
Subject: Re: Issue 3718 in lilypond: Patch: Web: Reword contactUsAbout macro
Date: Fri, 20 Dec 2013 11:12:46 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)

Urs Liska <address@hidden> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]