[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Fwd: Issue 3714 in lilypond: website: use colors to distinguish each
From: |
David Kastrup |
Subject: |
Re: Fwd: Issue 3714 in lilypond: website: use colors to distinguish each manual and stable vs. development |
Date: |
Sat, 21 Dec 2013 11:51:26 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) |
David Kastrup <address@hidden> writes:
> Carl Peterson <address@hidden> writes:
>
>> ---------- Forwarded message ----------
>> From: <address@hidden>
>> Date: Thu, Dec 19, 2013 at 5:33 AM
>> Subject: Re: Issue 3714 in lilypond: website: use colors to
>> distinguish each manual and stable vs. development
>> To: address@hidden
>>
>>
>> Updates:
>> Labels: -Patch-countdown Patch-push
>>
>> Comment #15 on issue 3714 by pkx166h: website: use colors to
>> distinguish each manual and stable vs. development
>> http://code.google.com/p/lilypond/issues/detail?id=3714
>>
>> Path counted down - please push. Carlo, I don't know if you have push
>> access, if not can you make a git formatted patch based on current
>> master and someone can push it for you.
>>
>> Patches attached. Can someone push?
>
> Pushed them to staging. Can you try word wrapping the lines of the
> commit messages next time? I noticed this only after pushing.
Oh, and rereading the commit messages right now, I saw
commit 5cf88b60c46b1194e6b68a869e40e6f3402aea6a
Author: Carl Peterson <address@hidden>
Date: Thu Dec 12 18:05:11 2013 -0500
fix sidebar colors in html documentation
Change the default color of the TOC sidebar when no manual-specific color ha
Also, darkened most of the manual TOC sidebars to separate from header and f
which looks like it fixes aspects in earlier patches of the series. If
you actually fix previous aspects of the _same_ patch series, you should
likely reorganize the series with
git rebase -i
before pushing: there is nothing gained by leaving a history of mistakes
and corrections in a patch series: try to organize it as though you got
everything right in the first try. Splitting a patch series into
separate patches should not be based on history but rather on splitting
the patch into logically distinct parts/steps.
Thanks!
--
David Kastrup