bug-lilypond
[Top][All Lists]
Advanced

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

Re: -dpreview crops staff bracket


From: David Kastrup
Subject: Re: -dpreview crops staff bracket
Date: Tue, 07 May 2013 10:31:04 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)

Janek Warchoł <address@hidden> writes:

> 2013/5/6 David Kastrup <address@hidden>:
>> Wow.
>>
>> commit 7b2cb93fc69c7d7c45f0ae6495f688752efeb107
>> Author: Mike Solomon <address@hidden>
>> Date:   Sat Mar 23 19:09:28 2013 +0100
>>
>>     Fixes manual beaming over rests and vertical spacing problem
>> (issue 3242)
>>
>> The patch set removes code that does not appear to have any relation to
>> the purported purpose of the patch and skimming over the code review, I
>> can see no explanation for that removal.  The removed code carries
>> comments regarding what it is supposed to be for, and apparently it was
>> not checked thoroughly that the removal does not affect that
>> functionality.
>
> What i'm most surprised about is the commit message.  There was a
> reasonable, quite helpful description in the Rietveld review (see
> https://codereview.appspot.com/7516048/) after i asked for
> explanations.  But it seems that Mike used previous Rietveld
> description as his commit message.  I don't quite see what kind of
> workflow could lead to such results, but apparently Mike's one does.
> Maybe it's time to move to gerrit for codereviews - from what i've
> read it seems to help with such issues...

Short of last-minute rewordings it should, as the reviews with Gerrit
are a git path including the commit messages.  Many of Mike's commit
messages appear like they are written from scratch at the time of the
commit, sometimes not containing anything that could help matching them
to the corresponding issue/review.  Gerrit would not help against that,
but it may be harder to pick a workflow where one would do this.

-- 
David Kastrup



reply via email to

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