Re: CG manual, pushing to staging

[David Kastrup]

Benkő Pál <address@hidden> writes:

> 2015-07-18 17:57 GMT+02:00 Federico Bruni <address@hidden>:
>> What do you think about these instructions?
>> http://lilypond.org/doc/v2.19/Documentation/contributor/pushing-to-staging
>>
>> I have a few comments, but I'm not sure about any of them:
>>
>> 1. There's no real purpose in pulling and rebasing the staging branch,
>> assuming that this branch should be "clean" (we should work on master or on
>> a local branch).
>
> agreed: I don't need a local master or staging branch at all.
> all my branches are based on origin/master;

That's my usual way of operation as well.  However, I used a local
master branch recently to assemble about 6 interlocking issues in
countdown into one coherent whole, and using that coherent whole both
for checking that the way that I combined those issues worked out, and
for putting another issue depending on those on review (by making the
review consist of two patches, the first being all the combined issues
on countdown, the second being the issue on top of that).

So I was able to put several severely interacting issues on the same
countdown in parallel, and got something dependent on it on the next
countdown.

Had I restrained myself to just working on single issues, the whole
batch would have taken at least 3 weeks instead of one.

So this time I was able to make sensible use of a local master branch in
order to keep stuff on countdown in an orderly prepared and tested
manner.

Most of the time though I don't have a local master.  And a local
staging does not make any sense at all in my opinion since it's quite a
nuisance to remove stuff that has been backed out of the upstream
staging, and the whole point of staging is that we back stuff out of it
again occasionally.

> I prefer working with local branches, using rebase instead of merge like
>
> $ git checkout my_branch_name
> $ git fetch
> $ git rebase origin/staging
> [fix conflicts, run all checks, repeat from fetch, etc.]
> $ git push origin HEAD:staging

I rarely rebase to origin/staging.  I rather rebase on origin/master or
my current HEAD.  If somebody else moved staging forward, I tend to wait
until master has caught up again, just in case that the current state of
staging has to be backed out for some reason.

-- 
David Kastrup