openlilylib-user — General openLilyLib discussion

[oll-user] Git for dummies

[David W. <da...@mu...>]

I am coming to GIT with zero background knowledge, and am absolutely *totally* confused.

I have installed GIT and GIT for windows (I’m running Windows 8), and can log on with my user name and password.   I pressed a ‘Fork’ button in the browser page, and the number next to it responded by changing from 7 to 8.

But I don’t know what this actually did, and I haven’t a clue what to do next.   I have a PDF file to upload, or ‘commit’ or whatever, but how do I do it?  I have to ‘clone’ a ‘repository’ but I have only the faintest idea of what a ‘repository’ is or what a ‘clone’ is (except possibly that the clone is possibly expected to be on my computer, and the repository is up in the cloud somewhere).

I started wading through the introduction to GIT but after several generally unhelpful pages of how it differs from other programs I’d never heard of, my eyes started to glaze over.   I have now spent almost as long on this as I spent encoding challenge 1.

Help!  Anyone?

Dave
David Webber
Mozart Music Software
http://www.mozart.co.uk/
-------------- next part --------------
An HTML attachment was scrubbed...

[oll-user] [Challenges] Challenge 2

[Phil H. <em...@ph...>]

Initial version now available at 
https://github.com/PhilHolmes/engraving-challenges/tree/master/challenge02-schumann/Sibelius-7

--
Phil Holmes

Re: [oll-user] Git workflow

[Urs L. <ul...@op...>]

Urs Liska <ul...@op...> schrieb:
>
>
>Phil Holmes <ma...@ph...> schrieb:
>>----- Original Message ----- 
>>From: "Urs Liska" <ul...@op...>
>>To: "Phil Holmes" <ma...@ph...>; 
>><ope...@li...>
>>Sent: Saturday, January 11, 2014 11:35 AM
>>Subject: Re: [oll-user] Git workflow
>>
>>
>>>
>>>
>>> Phil Holmes <ma...@ph...> schrieb:
>>>>----- Original Message ----- 
>>>>From: "Urs Liska" <ul...@op...>
>>>>To: <ope...@li...>
>>>>Sent: Friday, January 10, 2014 9:58 PM
>>>>Subject: Re: [oll-user] Git workflow
>>>>>
>>>>> Hm, just to be precise: you're not forking a branch but a
>>repository.
>>>>> That is: you have forked the complete repository, which contains
>>all
>>>>> branches.
>>>>> Maybe that's what you meant, I just think these issues have to be
>>>>clear.
>>>>
>>>>If I look at my git repo, it appears to be a snapshot when I forked
>>it
>>>>and
>>>>doesn't contain the later branch.
>>>
>>> Yes, that's the way it works.
>>>
>>>> I therefore can't checkout the
>>>>Schumann
>>>>branch.  How do I fix that?
>>>
>>> Assuming you have the fork as the "origin" and the main repo as the 
>>> "upstream" remote you can
>>>
>>> git fetch upstream
>>>
>>
>>I obviously don't:
>>
>>$ git fetch upstream
>>fatal: 'upstream' does not appear to be a git repository
>>fatal: The remote end hung up unexpectedly
>>
>>How do I set your repo as upstream?
>>
>
>git remote add upstream
>https.//github.com/openlilylib/engraving-challenges.git
>
>>--
>>Phil Holmes 

Of course with http://
-- 
Urs Liska
openlilylib.org

Re: [oll-user] Git workflow

[Urs L. <ul...@op...>]

Phil Holmes <ma...@ph...> schrieb:
>----- Original Message ----- 
>From: "Urs Liska" <ul...@op...>
>To: "Phil Holmes" <ma...@ph...>; 
><ope...@li...>
>Sent: Saturday, January 11, 2014 11:35 AM
>Subject: Re: [oll-user] Git workflow
>
>
>>
>>
>> Phil Holmes <ma...@ph...> schrieb:
>>>----- Original Message ----- 
>>>From: "Urs Liska" <ul...@op...>
>>>To: <ope...@li...>
>>>Sent: Friday, January 10, 2014 9:58 PM
>>>Subject: Re: [oll-user] Git workflow
>>>>
>>>> Hm, just to be precise: you're not forking a branch but a
>repository.
>>>> That is: you have forked the complete repository, which contains
>all
>>>> branches.
>>>> Maybe that's what you meant, I just think these issues have to be
>>>clear.
>>>
>>>If I look at my git repo, it appears to be a snapshot when I forked
>it
>>>and
>>>doesn't contain the later branch.
>>
>> Yes, that's the way it works.
>>
>>> I therefore can't checkout the
>>>Schumann
>>>branch.  How do I fix that?
>>
>> Assuming you have the fork as the "origin" and the main repo as the 
>> "upstream" remote you can
>>
>> git fetch upstream
>>
>
>I obviously don't:
>
>$ git fetch upstream
>fatal: 'upstream' does not appear to be a git repository
>fatal: The remote end hung up unexpectedly
>
>How do I set your repo as upstream?
>

git remote add upstream https.//github.com/openlilylib/engraving-challenges.git

>--
>Phil Holmes 


-- 
Urs Liska
openlilylib.org

Re: [oll-user] Git workflow

[Phil H. <ma...@ph...>]

----- Original Message ----- 
From: "Urs Liska" <ul...@op...>
To: "Phil Holmes" <ma...@ph...>; 
<ope...@li...>
Sent: Saturday, January 11, 2014 11:35 AM
Subject: Re: [oll-user] Git workflow


>
>
> Phil Holmes <ma...@ph...> schrieb:
>>----- Original Message ----- 
>>From: "Urs Liska" <ul...@op...>
>>To: <ope...@li...>
>>Sent: Friday, January 10, 2014 9:58 PM
>>Subject: Re: [oll-user] Git workflow
>>>
>>> Hm, just to be precise: you're not forking a branch but a repository.
>>> That is: you have forked the complete repository, which contains all
>>> branches.
>>> Maybe that's what you meant, I just think these issues have to be
>>clear.
>>
>>If I look at my git repo, it appears to be a snapshot when I forked it
>>and
>>doesn't contain the later branch.
>
> Yes, that's the way it works.
>
>> I therefore can't checkout the
>>Schumann
>>branch.  How do I fix that?
>
> Assuming you have the fork as the "origin" and the main repo as the 
> "upstream" remote you can
>
> git fetch upstream
>

I obviously don't:

$ git fetch upstream
fatal: 'upstream' does not appear to be a git repository
fatal: The remote end hung up unexpectedly

How do I set your repo as upstream?

--
Phil Holmes 

Re: [oll-user] Fw: [Challenges]: Sibelius

[David W. <da...@mu...>]

From: Janek Warchoł

> I'd prefer a pdf.  Jpegs have finite resolution and lossy compression that 
> introduces visible artifacts, both very unwelcome when reviewing an 
> engraving in detail.

In practice I've found that jpegs exported from Mozart at printer resolution 
are really quite acceptable.   But I can save GIF or PNG if it worries you. 
I'll see what I can do with PDF too.

(But first I have to master GITHUB, and from some of the messages here - it 
doesn't look that straightforward.)

Dave

Re: [oll-user] Git workflow

[Urs L. <ul...@op...>]

Phil Holmes <ma...@ph...> schrieb:
>----- Original Message ----- 
>From: "Urs Liska" <ul...@op...>
>To: <ope...@li...>
>Sent: Friday, January 10, 2014 9:58 PM
>Subject: Re: [oll-user] Git workflow
>>
>> Hm, just to be precise: you're not forking a branch but a repository.
>> That is: you have forked the complete repository, which contains all
>> branches.
>> Maybe that's what you meant, I just think these issues have to be
>clear.
>
>If I look at my git repo, it appears to be a snapshot when I forked it
>and 
>doesn't contain the later branch.  

Yes, that's the way it works.

> I therefore can't checkout the
>Schumann 
>branch.  How do I fix that?

Assuming you have the fork as the "origin" and the main repo as the "upstream" remote you can

git fetch upstream

To download everything new from there.
Then continue to merge or rather rebase appropriately.

HTH
Urs

>
>--
>Phil Holmes 


-- 
Urs Liska
openlilylib.org

Re: [oll-user] Git workflow

[Phil H. <ma...@ph...>]

----- Original Message ----- 
From: "Urs Liska" <ul...@op...>
To: <ope...@li...>
Sent: Friday, January 10, 2014 9:58 PM
Subject: Re: [oll-user] Git workflow
>
> Hm, just to be precise: you're not forking a branch but a repository.
> That is: you have forked the complete repository, which contains all
> branches.
> Maybe that's what you meant, I just think these issues have to be clear.

If I look at my git repo, it appears to be a snapshot when I forked it and 
doesn't contain the later branch.  I therefore can't checkout the Schumann 
branch.  How do I fix that?

--
Phil Holmes 

Re: [oll-user] schumann questions

[Janek W. <lem...@gm...>]

2014/1/11 Urs Liska <ul...@op...>

> Am Freitag, den 10.01.2014, 15:57 -0700 schrieb Marc Sabatella:
> > Really these are kind of general, but I am for now interesting in the
> > answer for the Schumann in particular.
> >
> > 1) To what extent are we trying to copy the exact layout?  Where the
> > line breaks occur, how the slurs attach, etc?  I could see arguments for
> > trying to copy exactly but also for using our own editorial judgement
> > (which would be influenced for most us, no doubt, by the defaults of our
> > chosen software).
>
> No, we're not trying to copy the model exactly.
> We're trying to make the best possible edition of the piece.
> (Of course for our purpose we're not interested in scholarly review or
> stuff like that).
> Being influenced by the default of the capabilities of the software
> isn't bad, not even in our context ;-)
>

However, using the same line breaks would make comparing versions from
different programs easier.

j
-------------- next part --------------
An HTML attachment was scrubbed...

Re: [oll-user] Fw: [Challenges]: Sibelius

[David W. <da...@mu...>]

Ok, I have Mozart's approximation to challenge 1, in the form of a JPEG 
file.  All I have to do is work out what this GitHub thing is all about, so 
I can upload it!   It's getting late here so tomorrow will have to do.

[Mozart doesn't really do 'snippets' so I created a piano piece in C and 
4/4, entered a dummy bar followed by a hard page break, and then the page of 
music which is challenge 1.   Rather than convert the whole thing including 
the junk at the start to a PDF file, it's simpler just to export page 2 as a 
JPEG.  Hope that's OK.]

Dave

David Webber
Mozart Music Software
http://www.mozart.co.uk/

Re: [oll-user] initial MuseScore 2.0 version of challenge02-schumann

[Marc S. <ma...@ou...>]

On 1/10/2014 5:39 PM, Urs Liska wrote:
> Yes, now you should open a pull request, but before you should do one 
> more thing: rebase your branch to 2-schumann-challenge. But in order 
> to do that we have to sort out the other issue with the remotes (in 
> the other mail) 

Done, I think.  I'm accustomed to rebasing and pull-requesting my own 
branches against the master branch of upstream (the MuseScore project 
doesn't use branches on the upstream repo - or at least, we aren't 
supposed to pay attention to them), but I believe I've sorted this out.

Marc

Re: [oll-user] Git workflow

[Urs L. <ul...@op...>]

Marc Sabatella <ma...@ou...> schrieb:
>On 1/10/2014 5:43 PM, Urs Liska wrote:
>> Somewhere there is a misconception, presumably on your side. What
>does 
>> Git remote -v tell you? When you add a remote this is only for the 
>> current repository. What repo do you think the name upstream is 
>> already used for?
>
>Aha!  "git remote -v" reports that upstream is defined as exactly what 
>it should be defined as.  Not sure if I accidentally did it twice, or
>if 
>the GitHub app did this for me when I asked to clone my fork,

That may well be

 but 
>anyhow, all is well.
>
>I'll issue the pull request right away, but I won't be working on this 
>further tonight anyhow.  Thanks for the help!

before you should do:

Git checkout 2-schumann-challenge
Git fetch upstream
Git rebase upstream/master
Git checkout musescore
Git rebase 2-schumann

(Everything with lowercase at the beginning)

Then make sure to open the request against openlilylib/2-schumann-challenge.

Good night.
Urs
>
>Marc


-- 
Urs Liska
openlilylib.org

Re: [oll-user] Git workflow

[Marc S. <ma...@ou...>]

On 1/10/2014 5:43 PM, Urs Liska wrote:
> Somewhere there is a misconception, presumably on your side. What does 
> Git remote -v tell you? When you add a remote this is only for the 
> current repository. What repo do you think the name upstream is 
> already used for?

Aha!  "git remote -v" reports that upstream is defined as exactly what 
it should be defined as.  Not sure if I accidentally did it twice, or if 
the GitHub app did this for me when I asked to clone my fork, but 
anyhow, all is well.

I'll issue the pull request right away, but I won't be working on this 
further tonight anyhow.  Thanks for the help!

Marc

Re: [oll-user] Git workflow

[Urs L. <ul...@op...>]

Marc Sabatella <ma...@ou...> schrieb:
>> Can you tell me exactly what you tried to do?
>
>Just the usual as far as I knew.  I was in a Git Bash shell in my local
>
>repo on my Windows 7 machine, and I typed:
>
>    git remote add upstream
>    git://github.com/openlilylib/engraving-challenges.git
>
>
>The error I got was:
>
>    fatal: remote upstream already exists
>
>which, indeed, it already does - for an entirely different repo.
>
>  This is on Windows 7, using Git Bash.
>


Somewhere there is a misconception, presumably on your side.
What does 
Git remote -v
tell you?

When you add a remote this is only for the current repository. 
What repo do you think the name upstream is already used for?

Urs
(PS: I will only be online for a few more minutes)

>Marc
>
>-------------- next part --------------
>An HTML attachment was scrubbed...
>------------------------------------------------------------------------------
>CenturyLink Cloud: The Leader in Enterprise Cloud Services.
>Learn Why More Businesses Are Choosing CenturyLink Cloud For
>Critical Workloads, Development Environments & Everything In Between.
>Get a Quote or Start a Free Trial Today. 
>http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
>_______________________________________________
>openlilylib-user mailing list
>ope...@li...
>https://lists.sourceforge.net/lists/listinfo/openlilylib-user


-- 
Urs Liska
openlilylib.org

Re: [oll-user] initial MuseScore 2.0 version of challenge02-schumann

[Urs L. <ul...@op...>]

Marc Sabatella <ma...@ou...> schrieb:
>I have created a branch on my fork for the Schumann challenge and 
>checked in a whole bunch of commits, culminating in the version I would
>
>like to submit for review.  As per the instructions - if I am 
>understanding correctly - this is notes and markings only, no 
>adjustments to page layout or other global settings, and no manual 
>adjustments (aside from the suppression of the rests for the incomplete
>
>voice throughout the LH and in bar 34 RH).  I posted both an MSCX file 
>(MuseScore text-based format) and a PDF, and some notes in the
>README.md
>
>I am not clear on whether I should submit a pull request now or wait 
>until I'm done, but you can view the files on my fork.  If I'm doing 
>this correctly, this link should take you there:
>
>https://github.com/MarcSabatella/engraving-challenges/tree/musescore/challenge02-schumann/MuseScore-2-0-devel
>
>Not too pretty out of the box, obviously, but I think I should be able 
>to clean it up well enough in pretty short order once I get the OK 
>(which I assume is the purpose of submitting for review).
>
>Marc
>
>
>------------------------------------------------------------------------------
>CenturyLink Cloud: The Leader in Enterprise Cloud Services.
>Learn Why More Businesses Are Choosing CenturyLink Cloud For
>Critical Workloads, Development Environments & Everything In Between.
>Get a Quote or Start a Free Trial Today. 
>http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
>_______________________________________________
>openlilylib-user mailing list
>ope...@li...
>https://lists.sourceforge.net/lists/listinfo/openlilylib-user

Congrats, looks really good.

Yes, now you should open a pull request, but before you should do one more thing: rebase your branch to 2-schumann-challenge.
But in order to do that we have to sort out the other issue with the remotes (in the other mail)
-- 
Urs Liska
openlilylib.org

[oll-user] initial MuseScore 2.0 version of challenge02-schumann

[Marc S. <ma...@ou...>]

I have created a branch on my fork for the Schumann challenge and 
checked in a whole bunch of commits, culminating in the version I would 
like to submit for review.  As per the instructions - if I am 
understanding correctly - this is notes and markings only, no 
adjustments to page layout or other global settings, and no manual 
adjustments (aside from the suppression of the rests for the incomplete 
voice throughout the LH and in bar 34 RH).  I posted both an MSCX file 
(MuseScore text-based format) and a PDF, and some notes in the README.md

I am not clear on whether I should submit a pull request now or wait 
until I'm done, but you can view the files on my fork.  If I'm doing 
this correctly, this link should take you there:

https://github.com/MarcSabatella/engraving-challenges/tree/musescore/challenge02-schumann/MuseScore-2-0-devel

Not too pretty out of the box, obviously, but I think I should be able 
to clean it up well enough in pretty short order once I get the OK 
(which I assume is the purpose of submitting for review).

Marc

Re: [oll-user] Git workflow

[Marc S. <ma...@ou...>]

> Can you tell me exactly what you tried to do?

Just the usual as far as I knew.  I was in a Git Bash shell in my local 
repo on my Windows 7 machine, and I typed:

    git remote add upstream
    git://github.com/openlilylib/engraving-challenges.git


The error I got was:

    fatal: remote upstream already exists

which, indeed, it already does - for an entirely different repo.

  This is on Windows 7, using Git Bash.

Marc

-------------- next part --------------
An HTML attachment was scrubbed...

Re: [oll-user] schumann questions

[Urs L. <ul...@op...>]

Am Freitag, den 10.01.2014, 15:57 -0700 schrieb Marc Sabatella:
> Really these are kind of general, but I am for now interesting in the 
> answer for the Schumann in particular.
> 
> 1) To what extent are we trying to copy the exact layout?  Where the 
> line breaks occur, how the slurs attach, etc?  I could see arguments for 
> trying to copy exactly but also for using our own editorial judgement 
> (which would be influenced for most us, no doubt, by the defaults of our 
> chosen software).

No, we're not trying to copy the model exactly.
We're trying to make the best possible edition of the piece.
(Of course for our purpose we're not interested in scholarly review or
stuff like that).
Being influenced by the default of the capabilities of the software
isn't bad, not even in our context ;-)

> 
> 2) Assuming we are trying to copy the layout, is there some way to be 
> sure of the original size of the notation and of the page?  I don't see 
> a way to get this info from the PNG that is - it doesn't appear to have 
> recorded a DPI value (and that seems a painfully indirect way of finding 
> the answers anyhow).

If we were trying that someone would have to go to a library and measure
everything, or rather make a reliable scan with clear DPI and a
reference length.
But as said above, that's not what we're after.

Urs

> 
> Marc
> 
> 
> ------------------------------------------------------------------------------
> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
> Learn Why More Businesses Are Choosing CenturyLink Cloud For
> Critical Workloads, Development Environments & Everything In Between.
> Get a Quote or Start a Free Trial Today. 
> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
> _______________________________________________
> openlilylib-user mailing list
> ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openlilylib-user

Re: [oll-user] schumann questions

[Marc S. <ma...@ou...>]

Really these are kind of general, but I am for now interesting in the 
answer for the Schumann in particular.

1) To what extent are we trying to copy the exact layout?  Where the 
line breaks occur, how the slurs attach, etc?  I could see arguments for 
trying to copy exactly but also for using our own editorial judgement 
(which would be influenced for most us, no doubt, by the defaults of our 
chosen software).

2) Assuming we are trying to copy the layout, is there some way to be 
sure of the original size of the notation and of the page?  I don't see 
a way to get this info from the PNG that is - it doesn't appear to have 
recorded a DPI value (and that seems a painfully indirect way of finding 
the answers anyhow).

Marc

Re: [oll-user] Git workflow

[Urs L. <ul...@op...>]

Am 10.01.2014 23:47, schrieb Marc Sabatella:
> On 1/10/2014 2:58 PM, Urs Liska wrote:
>> Are we supposed to be forking branches rather than the master?
>> Hm, just to be precise: you're not forking a branch but a repository.
>> That is: you have forked the complete repository, which contains all
>> branches.
>> Maybe that's what you meant, I just think these issues have to be clear.
>
> Yes, thank you.  At some level I do understand forking is the whole
> repo, but while I'd like to say this was a slip of the tongue, the
> reality is, I have to slow down and think clearly with git.
>
>> Now to the branching strategy.
>
> Thanks, that made perfect sense.
>
> One thing: I already use "upstream" as an alias for the main MuseScore
> source repo.  I would have thought Git would be smart enough to make
> these aliases repo-specific, but apparently not - it complained
> "upstream" was already in use.  Or am I doing something wrong?

Definitely.
Can you tell me exactly what you tried to do?

>
> Marc
>
>
> ------------------------------------------------------------------------------
> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
> Learn Why More Businesses Are Choosing CenturyLink Cloud For
> Critical Workloads, Development Environments & Everything In Between.
> Get a Quote or Start a Free Trial Today.
> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
> _______________________________________________
> openlilylib-user mailing list
> ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openlilylib-user
>


-- 
Urs Liska
www.openlilylib.org

Re: [oll-user] Git workflow

[Marc S. <ma...@ou...>]

On 1/10/2014 2:58 PM, Urs Liska wrote:
> Are we supposed to be forking branches rather than the master?
> Hm, just to be precise: you're not forking a branch but a repository.
> That is: you have forked the complete repository, which contains all
> branches.
> Maybe that's what you meant, I just think these issues have to be clear.

Yes, thank you.  At some level I do understand forking is the whole 
repo, but while I'd like to say this was a slip of the tongue, the 
reality is, I have to slow down and think clearly with git.

> Now to the branching strategy.

Thanks, that made perfect sense.

One thing: I already use "upstream" as an alias for the main MuseScore 
source repo.  I would have thought Git would be smart enough to make 
these aliases repo-specific, but apparently not - it complained 
"upstream" was already in use.  Or am I doing something wrong?

Marc

Re: [oll-user] [Challenges] New challenge

[Urs L. <ul...@op...>]

Am 10.01.2014 20:25, schrieb Janek Warchoł:
> 2014/1/10 Urs Liska <ul...@op...>
>
>> I've put up a new challenge:
>>
>> https://github.com/openlilylib/engraving-challenges/blob/2-schumann-challenge/challenge02-schumann/README.md
>>
>
> Looks nice.
> Should you perhaps move the master branch to include appropriate commit?
>
> 2014/1/10 Phil Holmes <ma...@ph...>
>
>> I would like to see a vocal challenge: something like solo voice with
>> piano.
>>
>
> +1, and also maybe single-staff solo instrument.
> And maybe SATB choir.  that should cover a wide range of engraving issues.
>
> Janek
>

Of course we're going to extend this, but one after another.

voice/piano is of course my favourite combination, this actually makes 
the biggest portion of my physical scores. The songs of Vaughan Williams 
are very nice, but of course copyright.
One candidate with very complex songs would be Alban Berg. But there 
would be interesteing ones with Liszt for example.

Urs

-- 
Urs Liska
www.openlilylib.org

Re: [oll-user] Git workflow

[Urs L. <ul...@op...>]

Am 10.01.2014 20:21, schrieb Marc Sabatella:
> Seems once upon a time (like, within the last 24 hours :-) I saw
> something where the basic git workflow fopr the project in terms for
> first forking then cloning etc was described.  This doens't seem to be
> in the actual git workflow document; where is it?

Maybe it has become a victim of some "streamlining". It was suggested to 
make some things about Git workflows less prominent.

I could try to find it in the repo history, but I think it isn't worth 
it. I'd rather explain concretely.

>
> Trying to find my way through on my own, the first noteworthy thing I
> see is that the schumann example is not on the master branch.  Is that
> right?

THat's true but not right. I mean it's an error that the assignment 
isn't on the master branch. I either missed to update that master branch 
or I actually did but forgot to push (that was in a different part of 
town so I can't simply check).

_Just now_ I have moved master forward by two commits, so master now 
contains the two assignments.

> Are we supposed to be forking branches rather than the master?

Hm, just to be precise: you're not forking a branch but a repository.
That is: you have forked the complete repository, which contains all 
branches.
Maybe that's what you meant, I just think these issues have to be clear.

Now to the branching strategy.
The master branch should only move forward when a challenge is (more or 
less) complete.
After a challenge is displayed (that is what I did wrong with the 
Schumann challenge) a new base branch should be created, in that case 
it's called 2-schumann-challenge.
When you want to do some work you should do:
git checkout 2-schumann-challenge
% to activate the 'base' branch
git checkout -b schumann-marc-note-entry
% or whatever name you want to give it

The second command creates a new branch for you that is based on the 
challenge's base branch.

Now you'll add commits to that branch until one phase is finished, say 
the initial music entry.

Next thing will be to merge your working branch into the 
2-schumann-challenge branch, but I suggest that we'll discuss this when 
you're there.

I have already done this once, with a Schumann branch. When I finished 
the initial entry I merged that work into the base branch, and history 
now looks like (simplified):

*   merge Urs' music entry into 2-schumann-challenge
|\
| * Urs: do some work
| |
| * Urs: do some work
|/
*   present the challenge = HEAD of master (now that I've updated it)


But currently this is only present on the "official" repository and not 
in your fork (changes aren't propagated automatically).

I suppose you added the "openlilylib/engraving-challenges" as the remote 
"upstream"
(through git remote add upstream 
https://github.com/openlilylib/engraving-challenges.git)

Then you can now do
git fetch upstream

This will download all commits from the upstream repository that aren't 
on your computer. Or in this case this will tell your local repository 
that the pointer on the master branch has moved.
If you want your local repository to be up to date you should do:

git checkout master
git merge upstream/master

This will make your master branch consistent with the upstream one.
Now you can do
git push origin

And this will push your local master branch to "origin" (which is your 
fork on Github).
(actually you can use "git push" alone in this case).

But now I really should stop flooding you ;-)
Best
Urs

[oll-user] first impressions about lilypond's attempt at challenge 2

[Janek W. <lem...@gm...>]

2014/1/10 Urs Liska <ul...@op...>

> PS: I've pushed the plain music entry of the Schumann example:
>
> https://github.com/openlilylib/engraving-challenges/tree/2-schumann-challenge/challenge02-schumann/LilyPond-custom
>
> I'm not too excited about the result. Particularly the piano-centered
> dynamics had a significant negative impact. But I think this will easily
> be fixed later.
>

Indeed.  However, i have some good news concerning slurs.  They look ugly,
but just try using


 \attach #'(0.5 stem) Slur


on them... (
https://github.com/openlilylib/snippets/blob/master/notation-snippets/shaping-bezier-curves/slur-attachments-example.ly
)


!!


j
-------------- next part --------------
An HTML attachment was scrubbed...

Re: [oll-user] [Challenges] New challenge

[Janek W. <lem...@gm...>]

2014/1/10 Urs Liska <ul...@op...>

> I've put up a new challenge:
>
> https://github.com/openlilylib/engraving-challenges/blob/2-schumann-challenge/challenge02-schumann/README.md
>

Looks nice.
Should you perhaps move the master branch to include appropriate commit?

2014/1/10 Phil Holmes <ma...@ph...>

> I would like to see a vocal challenge: something like solo voice with
> piano.
>

+1, and also maybe single-staff solo instrument.
And maybe SATB choir.  that should cover a wide range of engraving issues.

Janek
-------------- next part --------------
An HTML attachment was scrubbed...