Re: Staging/Master Merge - James' Patchy
Phil Holmes m...@philholmes.net writes: If I could have worked out how to split them, while at the same time being able to keep track of what changes were still needed, I would have done. However, doing things like having a screech-boink.ly in new, with a screech-and-boink.ly in snippets, and remembering to keep checking that the docs were all up to date and the one in new could be deleted was too much for my brain. The problem was that I believe I needed to get them into a single patch for the benefit of patchy, but I had them in six patches on my system. I git apply-ed each patch, but didn't remember to git add the files. TBH that seems a duff aspect of git. No, it isn't. git apply _only_ touches the work directory, so whatever happens, git does not remember anything about it. Use git apply --index if you want git to also _register_ the changes. Any other changes to the repo it can deal with. No. git does _not_ track _any_ change in the work directory unless you commit it to the index. Add a file and you need to remember to git add it. I've now got an even more humungous patch which includes the added files. My preference would be to push to staging, patchy and revert if there's a problem. What's the syntax for a revert? We use the staging branch exactly to avoid having to revert stuff. Instead we reset staging. Only stuff that percolated to master needs to get reverted in order to remove it. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Staging/Master Merge - James' Patchy
- Original Message - From: David Kastrup d...@gnu.org To: lilypond-devel@gnu.org We use the staging branch exactly to avoid having to revert stuff. Instead we reset staging. Only stuff that percolated to master needs to get reverted in order to remove it. -- David Kastrup What's the syntax to do that, please? -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Staging/Master Merge - James' Patchy
Phil Holmes m...@philholmes.net writes: - Original Message - From: David Kastrup d...@gnu.org To: lilypond-devel@gnu.org We use the staging branch exactly to avoid having to revert stuff. Instead we reset staging. Only stuff that percolated to master needs to get reverted in order to remove it. -- David Kastrup What's the syntax to do that, please? git push origin :staging (deletes the current staging branch) git push origin whatever_committish:refs/heads/staging whatever_committish is the commit you want to end up as staging instead of the previous one. The previous staging branch is lost. You better know what you are doing. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Update Rietveld patches
Both done - closing issues on Rietveld and adding 2310 to Rietveld's title. On 3 April 2012 04:00, Colin Campbell c...@shaw.ca wrote: Tools which we have written for the purpose are aware of the two unconnected sources of information about patches and have been modified to allow you to refer to an existing issue number (2310) when uploading a patch to Rietveld (5975054), but this only handles one side of the connection: in the Google issue, the Rietveld issue number is added, but the only way to get the connection from Rietveld, at least at the moment and as far as I understand it, is to ask the developer to refer to the Google tracker number in the title or summary of the issue. You might, for example, simply change the title of 5975054 to T2310 Corrected comments and a function check_meshing_chords divided in two and it would be clear at a glance where the rest of the conversation can be found. Shouldn't git cl be rewritten to change the title of Rietveld issue to include Google Code's issue numer? Łukasz ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Update Rietveld patches
On Tue, Apr 10, 2012 at 2:58 PM, Łukasz Czerwiński milimet...@gmail.com wrote: Shouldn't git cl be rewritten to change the title of Rietveld issue to include Google Code's issue numer? sure, go ahead. I don't have time because of gsoc. cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
PATCH: Countdown to 20120412
For 20:00 MDT Thursday April 12 Enhancement: Issue 2470 http://code.google.com/p/lilypond/issues/detail?id=2470: Patch: introduce completionUnit - R5987060 http://codereview.appspot.com/5987060/ Issue 2427 http://code.google.com/p/lilypond/issues/detail?id=2427: Patch: Add an example implementation of cross-staff stems - R5882053 http://codereview.appspot.com/5882053/ Ugly: Issue 2344 http://code.google.com/p/lilypond/issues/detail?id=2344: Kievan final barline gets cut off - R5727051 http://codereview.appspot.com/5727051/ Cheers, Colin -- I've learned that you shouldn't go through life with a catcher's mitt on both hands. You need to be able to throw something back. -Maya Angelou, poet (1928- ) ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypond bug 2368
On Wed, Apr 11, 2012 at 2:36 AM, Colin Hall colingh...@gmail.com wrote: On Sat, Apr 07, 2012 at 05:32:28PM +0200, Karol Majewski wrote: Is it possible to mark 2368 bug as critical? I think this kind of regression is a serious problem. Just take a look at my last comment: http://code.google.com/p/lilypond/issues/detail?id=2368#c6 I agree with you that the notation output is not correct, especially in the sample you provide in comment 6. I'm going to do my best to explain why this issue should not be marked critical. I hope that others will correct my statements as necessary. You might not be aware that there are several open issues for Lilypond that relate to the typesetting of ties and slurs. For example see issue 298, referenced from issue 2368. http://code.google.com/p/lilypond/issues/detail?id=298 There are others. As I understand it the development team have identified that a better implementation of ties is possible but requires aesthetic design work to establish how this feature should work before technical implementation work can begin. The technical work may be substantial. Yes, i do think that it will make more sense to rewrite tie code bearing in mind all bad tie cases instead of fixing the issues one by one. Besides, i suppose that marking this as critical will have only one result: next stable release will be postponed for 3 months or so. It won't make the bug fixed immediately, nor even soon. Janek has a study of Lilypond's typesetting of ties and slurs which is work in progress and which may provide the aesthetic design we need. He mentioned it in response to your original bug report: http://lists.gnu.org/archive/html/bug-lilypond/2012-02/msg01203.html Yes. The bad news is that i won't have time to finish it until summer. However, if there's anyone willing to finish it, i can share my results and provide some guidance. The task requires aesthetic sense and analytical skills, and i estimate 40 hours of work is needed to finish the tie analysis - no idea how long implementation will take. Bottom line: find someone to finish tie report and implement it's conclusions (or pay David to implement them - i will add €50 from myself if this is done before May 15). i hope that didn't sound too discouraging :) Janek PS Karol, are you a (former) student of Warsaw University of Technology, Faculty of Electronics (Elka)? ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
