openlilylib-user

[oll-user] Engraving challenge

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

I've started to look at the engraving challenge, and one thing that I think 
makes this not the best challenge: it looks like it's just a page from a 
piece, rather than the piece itself.  As a result, there's no title 
information, etc., and not even a time signature.  I presume it's 4/4 and 
will use this, but without messing around that will put one extraneous 
element on the output from Sibelius: i.e. a time signature.

The other issue is that this is clearly an odd piece of music - the beaming 
patterns are very atypical, and any music typesetting program with require 
substantial hacking to set this.  Some of the crossing notes are not really 
all that easy to read - see the 2nd beat of bar 3, for example.  And I 
assume there's lots of unmarked triplets all over the place?  Would it not 
be better to start with a piece that follows the recommendations of the 
typesetting manuals?

--
Phil Holmes

[oll-user] Engraving challenge

[Shane B. <sh...@gr...>]

Greetings all,

I figured out how to make the Git thing work more or less. A few
observations prior to starting. This music is not terribly complex
compared even to Liszt or even some Brahms stuff. I think it was a
good choice in terms of providing a certain level of complexity of
balancing things on the page that must be done by the program. Lunch
first and the task.

Shane

Re: [oll-user] Engraving challenge

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

Am 10.01.2014 19:20, schrieb Shane Brandes:
> Greetings all,
>
> I figured out how to make the Git thing work more or less.

Good.

> A few
> observations prior to starting. This music is not terribly complex
> compared even to Liszt or even some Brahms stuff. I think it was a
> good choice in terms of providing a certain level of complexity of
> balancing things on the page that must be done by the program.

Which one are you talking about, Schumann or Chopin/Godowsky?

Urs

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. (For more see the commit messages.

One thing: I've (stupidly) copied from my paper copy of Henle,
now I see that it has considerable differences against the Clara 
Schumann edition.
I will fix that and follow the older one that is uploaded on Github.

> Lunch
> first and the task.
>
> Shane
>

[oll-user] Git workflow

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

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?

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?  Are we supposed to be forking branches rather than the master?

Marc

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

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] 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] 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] 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

[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] 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...

[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] 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

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] 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:
>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] 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

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

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

I've gone ahead and make a first round of layout optimizations and 
manual adjustments - basically corresponding to how far I'd take this 
for my own purposes.  Meaning, I didn't fuss a whole lot with manually 
adjusting the shape or slurs etc, I just got things into the ballpark.  
And for lack of any better ideas, I emulated the original layout in 
terms of number of measures per system, spacing, etc.

Here's my folder in my fork:

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

I included reasonably detailed notes on my work in the README.

I thought I was being clever in including an SVG version, since in 
principle Git can track these better than PDF or PNG.  But if there is a 
straightforward way to force GitHub to deliver this to a browser in a 
way that allows the browser to actually render it, I haven't found it 
(apparently there is some whole other site called github.io that 
provides this functionality).  So I posted my SVG somewhere else to make 
it easier to include a link so people can view the results make 
suggestions without having to figure out how to access the file from 
GitHub.  Here it is:

http://musescore.org/sites/musescore.org/files/schumann.svg

Marc

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] 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: "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] 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

[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

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

On 1/10/2014 5:56 PM, Urs Liska wrote:
> 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.

This is *almost* but not quite what I figured out on my own.  In the 
third step above, I did the rebase against upstream/2-schumann-challenge 
instead of upstream/master - basically, I did a global replace of 
everywhere I normally would have used "master", changing it to 
2-schumann-challenge.  And I assume your fifth step above is a typo and 
should have been a 2-schumann-challenge.

I'm still green enough with Git to not be able to figure out for myself 
what the difference between "git rebase upstream/master" and "git rebase 
upstream/2-schumann-challenge" is in this context.  Did I screw things 
up badly enough that I need to redo all this, or if the pull request 
usable as is?

Anyhow, this whole series of step - including instructions on how to 
open a PR against a branch (since it seems to default to master) should 
probably go in the workflow document.

Marc

Re: [oll-user] Git workflow

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

Am Samstag, den 11.01.2014, 10:09 -0700 schrieb Marc Sabatella:
> On 1/10/2014 5:56 PM, Urs Liska wrote:
> > 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.
> 
> This is *almost* but not quite what I figured out on my own.  In the 
> third step above, I did the rebase against upstream/2-schumann-challenge 
> instead of upstream/master - basically, I did a global replace of 
> everywhere I normally would have used "master", changing it to 
> 2-schumann-challenge.  And I assume your fifth step above is a typo and 
> should have been a 2-schumann-challenge.
> 
> I'm still green enough with Git to not be able to figure out for myself 
> what the difference between "git rebase upstream/master" and "git rebase 
> upstream/2-schumann-challenge" is in this context.  Did I screw things 
> up badly enough that I need to redo all this, or if the pull request 
> usable as is?
> 
> Anyhow, this whole series of step - including instructions on how to 
> open a PR against a branch (since it seems to default to master) should 
> probably go in the workflow document.
> 
> Marc
> 

I will look into this in detail later tonight.