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

[David Kastrup]

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