Re: [Mutopia-discuss] clean pull requests?

[Knute Snortum]

Got it.  It took me a while because this is backwards from the way I used
to use Git for my software projects.  That's not to say anything is wrong
with it!  There are all sorts of ways to use Git.  I'm just getting used to
the Mutopia way of doing things.


Knute Snortum
(via Gmail)


On Wed, May 14, 2014 at 11:24 AM, Glen Larsen  wrote:

> Of course this will work --- "master" is a branch like any other branch
> and you could specify "master" in your pull request. It is not recommended
> practice because:
>
>- You now have to wait until that pull request is processed to submit
>other work
>- If you now create a branch that change is part of the new branch
>- You are presuming that your pull will be accepted
>- Ideally, you want the master in your fork repository to always match
>the fork in the upstream master.
>
> Creating a branch is cheap and mostly convenient. And yes, I understand
> the difficulty of multiple development branches where you want some bit of
> code from a sibling branch.
>
> Even in my own personal projects I don't ever edit in the master branch.
>
>
> [ ... snipped ... ]
>
___
Mutopia-discuss mailing list
Mutopia-discuss@mutopiaproject.org
http://lists.bcn.mythic-beasts.com/mailman/listinfo/mutopia-discuss

Re: [Mutopia-discuss] clean pull requests?

[Glen Larsen]

Of course this will work --- "master" is a branch like any other branch and
you could specify "master" in your pull request. It is not recommended
practice because:

   - You now have to wait until that pull request is processed to submit
   other work
   - If you now create a branch that change is part of the new branch
   - You are presuming that your pull will be accepted
   - Ideally, you want the master in your fork repository to always match
   the fork in the upstream master.

Creating a branch is cheap and mostly convenient. And yes, I understand the
difficulty of multiple development branches where you want some bit of code
from a sibling branch.

Even in my own personal projects I don't ever edit in the master branch.


[ ... snipped ... ]
___
Mutopia-discuss mailing list
Mutopia-discuss@mutopiaproject.org
http://lists.bcn.mythic-beasts.com/mailman/listinfo/mutopia-discuss

Re: [Mutopia-discuss] clean pull requests?

[Knute Snortum]

Glen, help me to understand something.  If I created a file on master,
staged and committed only it, then created a pull request, you would have a
pull request with exactly one new file on it.  No need for branches.  What
advantages do the branches create?


Knute Snortum
(via Gmail)


On Wed, May 14, 2014 at 5:03 AM, Knute Snortum  wrote:

> Regarding pull requests: I would like to be able to see what is going to
> be on a pull request before I create it -- or be able to delete a pull
> request if it has commit on it I don't want.  From what I can see in
> GitHub, once you create a pull request, it's too late to modify it.  Is
> there some solution to this?
>
>
> Knute Snortum
> (via Gmail)
>
>
> On Wed, May 14, 2014 at 4:58 AM, Knute Snortum  wrote:
>
>> Regarding merge commits: I will (and have) stopped merging the topic
>> branches into main.  But there are merges I'm supposed to make:
>>
>> Synchronize with your local repository
>>
>> Make sure you are in your master branch (not one of your topic branches),
>> and fetch any upstream changes:
>>
>> $ git checkout master
>> $ git fetch upstream
>> $ git merge upstream/master
>>
>> From what I can see, this will cause merge commits when I create a pull
>> request.  Am I doing something wrong?  Not understanding?
>>
>>
>> Knute Snortum
>> (via Gmail)
>>
>>
>> On Tue, May 13, 2014 at 11:11 PM, Glen Larsen wrote:
>>
>>> On Tue, May 13, 2014 at 5:41 PM, Knute Snortum 
>>>  wrote:
>>>
 Frederico, I am confused by what you mean by a "merge commit."  Since
 it is something I should try to avoid, I should understand what it is.  Is
 it merging a branch into master and committing it?

>>>
>>> Any merge from another branch will cause GIT to insert a "merge commit"
>>> message into the log file.
>>>
>>>

 Glen, I know I'm new to Mutopia.  Help me understand why you are using
 git.  It seems you do not want any of the things (at least I) use git for.
  One file on one branch with no commit history.  Why not just send the
 files in via email?

>>>
>>> We want the history of changes made to the source files. By "squashing"
>>> commits I mean the process of compressing the series of commits you have
>>> used during development into a single commit using "git rebase -i" or
>>> something similar.
>>>
>>>

 I may be an edge case, but let me show you why the git model as I
 understand it adds complexity without any advantage (in fact, there is a
 major disadvantage.)

  So, to add a movement to a suite, I

- checkout master
- fetch upstream
- merge with master
- create a branch
- checkout the branch
- create the ly file
- add the ly file
- commit the ly file
- push the branch to my forked github account
- get on github
- select the new branch
- create a pull request
- delete the branch on github
- delete the branch on my local repository

 Instead of

- create the ly file
- send in the ly file via email

  Source code management systems are necessarily complex, but all we
>>> really want from them is to track history. The reason merging and rebasing
>>> are "powerful" is because they need to be for group collaboration. In the
>>> Mutopia environment collaboration happens differently than software
>>> projects.
>>>
>>>
 Does submitting the file via github make it easier for you?

>>>
>>> Absolutely. If you email it, Chris will be doing half of the steps you
>>> outline above.
>>>
>>>
  Because it makes it harder for me.  I'm not working at the moment to I
 have a lot of time and I like to spend a good chunk of it transcribing
 music.  This means I can sometimes do a movement in a day or two.  I
 currently have about seven files (and seven branches) that are not on the
 master.  I am still learning how to best create ly files.  I may have a
 trick or a section of code I want to reused from an older branch but
 because I can't merge back to master, I have to checkout the old branch,
 stow the file somewhere, checkout the new branch and pull in the file.  If
 I want something from several branches, this can be a real mess.

>>>
>>> I have run into this as well and I agree it gets more difficult with
>>> multiple branches under development.
>>>
>>>
 So why are we doing fourteen steps to get one file into git without
 version or commit history that no one is going to merge with anyway?

>>>
>>> I think you may have misunderstood me. My opinion is that the log file
>>> should contain log messages more relevant to its history than its
>>> development. For example, in a long piano piece I may choose to transcribe
>>> the treble staff, commit, then the bass, commit, dynamics, commit, then
>>> commit aesthetic and midi tweaks. But before I check it in, I may choose to
>>> squash those into "initial content for ..

Re: [Mutopia-discuss] clean pull requests?

[Knute Snortum]

Regarding pull requests: I would like to be able to see what is going to be
on a pull request before I create it -- or be able to delete a pull request
if it has commit on it I don't want.  From what I can see in GitHub, once
you create a pull request, it's too late to modify it.  Is there some
solution to this?


Knute Snortum
(via Gmail)


On Wed, May 14, 2014 at 4:58 AM, Knute Snortum  wrote:

> Regarding merge commits: I will (and have) stopped merging the topic
> branches into main.  But there are merges I'm supposed to make:
>
> Synchronize with your local repository
>
> Make sure you are in your master branch (not one of your topic branches),
> and fetch any upstream changes:
>
> $ git checkout master
> $ git fetch upstream
> $ git merge upstream/master
>
> From what I can see, this will cause merge commits when I create a pull
> request.  Am I doing something wrong?  Not understanding?
>
>
> Knute Snortum
> (via Gmail)
>
>
> On Tue, May 13, 2014 at 11:11 PM, Glen Larsen  wrote:
>
>> On Tue, May 13, 2014 at 5:41 PM, Knute Snortum 
>>  wrote:
>>
>>> Frederico, I am confused by what you mean by a "merge commit."  Since it
>>> is something I should try to avoid, I should understand what it is.  Is it
>>> merging a branch into master and committing it?
>>>
>>
>> Any merge from another branch will cause GIT to insert a "merge commit"
>> message into the log file.
>>
>>
>>>
>>> Glen, I know I'm new to Mutopia.  Help me understand why you are using
>>> git.  It seems you do not want any of the things (at least I) use git for.
>>>  One file on one branch with no commit history.  Why not just send the
>>> files in via email?
>>>
>>
>> We want the history of changes made to the source files. By "squashing"
>> commits I mean the process of compressing the series of commits you have
>> used during development into a single commit using "git rebase -i" or
>> something similar.
>>
>>
>>>
>>> I may be an edge case, but let me show you why the git model as I
>>> understand it adds complexity without any advantage (in fact, there is a
>>> major disadvantage.)
>>>
>>>  So, to add a movement to a suite, I
>>>
>>>- checkout master
>>>- fetch upstream
>>>- merge with master
>>>- create a branch
>>>- checkout the branch
>>>- create the ly file
>>>- add the ly file
>>>- commit the ly file
>>>- push the branch to my forked github account
>>>- get on github
>>>- select the new branch
>>>- create a pull request
>>>- delete the branch on github
>>>- delete the branch on my local repository
>>>
>>> Instead of
>>>
>>>- create the ly file
>>>- send in the ly file via email
>>>
>>>  Source code management systems are necessarily complex, but all we
>> really want from them is to track history. The reason merging and rebasing
>> are "powerful" is because they need to be for group collaboration. In the
>> Mutopia environment collaboration happens differently than software
>> projects.
>>
>>
>>> Does submitting the file via github make it easier for you?
>>>
>>
>> Absolutely. If you email it, Chris will be doing half of the steps you
>> outline above.
>>
>>
>>>  Because it makes it harder for me.  I'm not working at the moment to I
>>> have a lot of time and I like to spend a good chunk of it transcribing
>>> music.  This means I can sometimes do a movement in a day or two.  I
>>> currently have about seven files (and seven branches) that are not on the
>>> master.  I am still learning how to best create ly files.  I may have a
>>> trick or a section of code I want to reused from an older branch but
>>> because I can't merge back to master, I have to checkout the old branch,
>>> stow the file somewhere, checkout the new branch and pull in the file.  If
>>> I want something from several branches, this can be a real mess.
>>>
>>
>> I have run into this as well and I agree it gets more difficult with
>> multiple branches under development.
>>
>>
>>> So why are we doing fourteen steps to get one file into git without
>>> version or commit history that no one is going to merge with anyway?
>>>
>>
>> I think you may have misunderstood me. My opinion is that the log file
>> should contain log messages more relevant to its history than its
>> development. For example, in a long piano piece I may choose to transcribe
>> the treble staff, commit, then the bass, commit, dynamics, commit, then
>> commit aesthetic and midi tweaks. But before I check it in, I may choose to
>> squash those into "initial content for ..." because, IMO, the user doesn't
>> need or care to know how I chose to work on the piece.
>>
>> I don't think you are an edge case, in fact your workflow is similar to
>> mine. I just choose to minimize log messages.
>>
>>
>
___
Mutopia-discuss mailing list
Mutopia-discuss@mutopiaproject.org
http://lists.bcn.mythic-beasts.com/mailman/listinfo/mutopia-discuss

Re: [Mutopia-discuss] clean pull requests?

[Knute Snortum]

Regarding merge commits: I will (and have) stopped merging the topic
branches into main.  But there are merges I'm supposed to make:

Synchronize with your local repository

Make sure you are in your master branch (not one of your topic branches),
and fetch any upstream changes:

$ git checkout master
$ git fetch upstream
$ git merge upstream/master

>From what I can see, this will cause merge commits when I create a pull
request.  Am I doing something wrong?  Not understanding?


Knute Snortum
(via Gmail)


On Tue, May 13, 2014 at 11:11 PM, Glen Larsen  wrote:

> On Tue, May 13, 2014 at 5:41 PM, Knute Snortum  wrote:
>
>> Frederico, I am confused by what you mean by a "merge commit."  Since it
>> is something I should try to avoid, I should understand what it is.  Is it
>> merging a branch into master and committing it?
>>
>
> Any merge from another branch will cause GIT to insert a "merge commit"
> message into the log file.
>
>
>>
>> Glen, I know I'm new to Mutopia.  Help me understand why you are using
>> git.  It seems you do not want any of the things (at least I) use git for.
>>  One file on one branch with no commit history.  Why not just send the
>> files in via email?
>>
>
> We want the history of changes made to the source files. By "squashing"
> commits I mean the process of compressing the series of commits you have
> used during development into a single commit using "git rebase -i" or
> something similar.
>
>
>>
>> I may be an edge case, but let me show you why the git model as I
>> understand it adds complexity without any advantage (in fact, there is a
>> major disadvantage.)
>>
>> So, to add a movement to a suite, I
>>
>>- checkout master
>>- fetch upstream
>>- merge with master
>>- create a branch
>>- checkout the branch
>>- create the ly file
>>- add the ly file
>>- commit the ly file
>>- push the branch to my forked github account
>>- get on github
>>- select the new branch
>>- create a pull request
>>- delete the branch on github
>>- delete the branch on my local repository
>>
>> Instead of
>>
>>- create the ly file
>>- send in the ly file via email
>>
>> Source code management systems are necessarily complex, but all we really
> want from them is to track history. The reason merging and rebasing are
> "powerful" is because they need to be for group collaboration. In the
> Mutopia environment collaboration happens differently than software
> projects.
>
>
>> Does submitting the file via github make it easier for you?
>>
>
> Absolutely. If you email it, Chris will be doing half of the steps you
> outline above.
>
>
>>  Because it makes it harder for me.  I'm not working at the moment to I
>> have a lot of time and I like to spend a good chunk of it transcribing
>> music.  This means I can sometimes do a movement in a day or two.  I
>> currently have about seven files (and seven branches) that are not on the
>> master.  I am still learning how to best create ly files.  I may have a
>> trick or a section of code I want to reused from an older branch but
>> because I can't merge back to master, I have to checkout the old branch,
>> stow the file somewhere, checkout the new branch and pull in the file.  If
>> I want something from several branches, this can be a real mess.
>>
>
> I have run into this as well and I agree it gets more difficult with
> multiple branches under development.
>
>
>> So why are we doing fourteen steps to get one file into git without
>> version or commit history that no one is going to merge with anyway?
>>
>
> I think you may have misunderstood me. My opinion is that the log file
> should contain log messages more relevant to its history than its
> development. For example, in a long piano piece I may choose to transcribe
> the treble staff, commit, then the bass, commit, dynamics, commit, then
> commit aesthetic and midi tweaks. But before I check it in, I may choose to
> squash those into "initial content for ..." because, IMO, the user doesn't
> need or care to know how I chose to work on the piece.
>
> I don't think you are an edge case, in fact your workflow is similar to
> mine. I just choose to minimize log messages.
>
>
___
Mutopia-discuss mailing list
Mutopia-discuss@mutopiaproject.org
http://lists.bcn.mythic-beasts.com/mailman/listinfo/mutopia-discuss

Re: [Mutopia-discuss] clean pull requests?

[Glen Larsen]

On Tue, May 13, 2014 at 5:41 PM, Knute Snortum  wrote:

> Frederico, I am confused by what you mean by a "merge commit."  Since it
> is something I should try to avoid, I should understand what it is.  Is it
> merging a branch into master and committing it?
>

Any merge from another branch will cause GIT to insert a "merge commit"
message into the log file.


>
> Glen, I know I'm new to Mutopia.  Help me understand why you are using
> git.  It seems you do not want any of the things (at least I) use git for.
>  One file on one branch with no commit history.  Why not just send the
> files in via email?
>

We want the history of changes made to the source files. By "squashing"
commits I mean the process of compressing the series of commits you have
used during development into a single commit using "git rebase -i" or
something similar.


>
> I may be an edge case, but let me show you why the git model as I
> understand it adds complexity without any advantage (in fact, there is a
> major disadvantage.)
>
> So, to add a movement to a suite, I
>
>- checkout master
>- fetch upstream
>- merge with master
>- create a branch
>- checkout the branch
>- create the ly file
>- add the ly file
>- commit the ly file
>- push the branch to my forked github account
>- get on github
>- select the new branch
>- create a pull request
>- delete the branch on github
>- delete the branch on my local repository
>
> Instead of
>
>- create the ly file
>- send in the ly file via email
>
> Source code management systems are necessarily complex, but all we really
want from them is to track history. The reason merging and rebasing are
"powerful" is because they need to be for group collaboration. In the
Mutopia environment collaboration happens differently than software
projects.


> Does submitting the file via github make it easier for you?
>

Absolutely. If you email it, Chris will be doing half of the steps you
outline above.


>  Because it makes it harder for me.  I'm not working at the moment to I
> have a lot of time and I like to spend a good chunk of it transcribing
> music.  This means I can sometimes do a movement in a day or two.  I
> currently have about seven files (and seven branches) that are not on the
> master.  I am still learning how to best create ly files.  I may have a
> trick or a section of code I want to reused from an older branch but
> because I can't merge back to master, I have to checkout the old branch,
> stow the file somewhere, checkout the new branch and pull in the file.  If
> I want something from several branches, this can be a real mess.
>

I have run into this as well and I agree it gets more difficult with
multiple branches under development.


> So why are we doing fourteen steps to get one file into git without
> version or commit history that no one is going to merge with anyway?
>

I think you may have misunderstood me. My opinion is that the log file
should contain log messages more relevant to its history than its
development. For example, in a long piano piece I may choose to transcribe
the treble staff, commit, then the bass, commit, dynamics, commit, then
commit aesthetic and midi tweaks. But before I check it in, I may choose to
squash those into "initial content for ..." because, IMO, the user doesn't
need or care to know how I chose to work on the piece.

I don't think you are an edge case, in fact your workflow is similar to
mine. I just choose to minimize log messages.
___
Mutopia-discuss mailing list
Mutopia-discuss@mutopiaproject.org
http://lists.bcn.mythic-beasts.com/mailman/listinfo/mutopia-discuss

Re: [Mutopia-discuss] clean pull requests?

[Knute Snortum]

Frederico, I am confused by what you mean by a "merge commit."  Since it is
something I should try to avoid, I should understand what it is.  Is it
merging a branch into master and committing it?

Glen, I know I'm new to Mutopia.  Help me understand why you are using git.
 It seems you do not want any of the things (at least I) use git for.  One
file on one branch with no commit history.  Why not just send the files in
via email?

I may be an edge case, but let me show you why the git model as I
understand it adds complexity without any advantage (in fact, there is a
major disadvantage.)

So, to add a movement to a suite, I

   - checkout master
   - fetch upstream
   - merge with master
   - create a branch
   - checkout the branch
   - create the ly file
   - add the ly file
   - commit the ly file
   - push the branch to my forked github account
   - get on github
   - select the new branch
   - create a pull request
   - delete the branch on github
   - delete the branch on my local repository

Instead of

   - create the ly file
   - send in the ly file via email

Does submitting the file via github make it easier for you?  Because it
makes it harder for me.  I'm not working at the moment to I have a lot of
time and I like to spend a good chunk of it transcribing music.  This means
I can sometimes do a movement in a day or two.  I currently have about
seven files (and seven branches) that are not on the master.  I am still
learning how to best create ly files.  I may have a trick or a section of
code I want to reused from an older branch but because I can't merge back
to master, I have to checkout the old branch, stow the file somewhere,
checkout the new branch and pull in the file.  If I want something from
several branches, this can be a real mess.

So why are we doing fourteen steps to get one file into git without version
or commit history that no one is going to merge with anyway?


Knute Snortum
(via Gmail)


On Tue, May 13, 2014 at 3:27 PM, Glen Larsen  wrote:

> In Mutopia there is typically no real need to merge other updates into a
> development branch because [1] it doesn't have dependencies to other parts
> of the Mutopia archive and [2] changes to a single piece within the archive
> are done by a single individual.
>
> I would prefer a minimal number of commit messages so I may add some
> pointers to resources explaining how to squash commits in GIT.
>
> [Thanks for the wiki edits, Federico!]
>
>
> On Tue, May 13, 2014 at 3:14 PM, Federico Bruni wrote:
>
>> Il giorno mar 13 mag 2014 alle 23:09, Javier Ruiz-Alma <
>> jav...@ruiz-alma.com> ha scritto:
>>
>>  Hi Federico,
>> Glen graciously added instructions on how to setup your github fork, and
>> basic 
>> workflow
>>  involved
>> in maintaining existing pieces in Mutopia using github.
>> He also a started a document to highlight LilyPond coding 
>> practices
>>  for
>> new submissions to Mutopia, which enhance the maintainability moving
>> forward.
>>
>> Today, I drafted a new doc covering new submissions:
>>
>> https://github.com/chrissawer/The-Mutopia-Project/wiki/Guidelines-for-new-score-submissions-using-github
>>
>> Github has proven to be a great environment for code collaboration, and we
>> welcome contributors using pull-requests.
>>
>> Javier Ruiz-Alma
>>
>>
>>On Tuesday, May 13, 2014 8:29 AM, Federico Bruni 
>> wrote:
>>
>> I've just given a quick glance to the pull requests sent today by
>> ksnortum.
>> I see a lot of merge commits which are unnecessary. I don't know how
>> this is sorted out when merging..
>>
>> I'm writing here to get some feedback on how to improve our wiki:
>>
>> https://github.com/chrissawer/The-Mutopia-Project/wiki/Setting-up-for-Contributions-via-GITHUB
>>
>> I usually try to avoid any merge commit in my pull requests. I think
>> that it's all about rebasing instead of merging, right?
>> It should be quite easy for us, I think, since we usually organize and
>> book the files to be added/updated.
>>
>> Suggestions are welcomed.
>> Thanks
>> Federico
>>
>> ___
>> Mutopia-discuss mailing list
>> Mutopia-discuss@mutopiaproject.org
>> http://lists.bcn.mythic-beasts.com/mailman/listinfo/mutopia-discuss
>>
>>
>>   Thanks Javier, this new page was the missing bit!
>> I've updated the main page of the wiki and added an "index" of the
>> articles (even if there's an automatic list under Pages on the right).
>>
>> It seems that wiki links are better: - [[|]]
>> https://help.github.com/articles/adding-links-to-wikis
>>
>> https://github.com/chrissawer/The-Mutopia-Project/wiki
>>
>>
>> ___
>> Mutopia-discuss mailing list
>> Mutopia-discuss@mutopiaproject.org
>> http://lists.bcn.mythic-beasts.com/mailman/listinfo/mutopia-discuss
>>
>
>
> _

Re: [Mutopia-discuss] clean pull requests?

[Glen Larsen]

In Mutopia there is typically no real need to merge other updates into a
development branch because [1] it doesn't have dependencies to other parts
of the Mutopia archive and [2] changes to a single piece within the archive
are done by a single individual.

I would prefer a minimal number of commit messages so I may add some
pointers to resources explaining how to squash commits in GIT.

[Thanks for the wiki edits, Federico!]


On Tue, May 13, 2014 at 3:14 PM, Federico Bruni  wrote:

> Il giorno mar 13 mag 2014 alle 23:09, Javier Ruiz-Alma <
> jav...@ruiz-alma.com> ha scritto:
>
> Hi Federico,
> Glen graciously added instructions on how to setup your github fork, and
> basic 
> workflow
>  involved
> in maintaining existing pieces in Mutopia using github.
> He also a started a document to highlight LilyPond coding 
> practices
>  for
> new submissions to Mutopia, which enhance the maintainability moving
> forward.
>
> Today, I drafted a new doc covering new submissions:
>
> https://github.com/chrissawer/The-Mutopia-Project/wiki/Guidelines-for-new-score-submissions-using-github
>
> Github has proven to be a great environment for code collaboration, and we
> welcome contributors using pull-requests.
>
> Javier Ruiz-Alma
>
>
>   On Tuesday, May 13, 2014 8:29 AM, Federico Bruni 
> wrote:
>
> I've just given a quick glance to the pull requests sent today by
> ksnortum.
> I see a lot of merge commits which are unnecessary. I don't know how
> this is sorted out when merging..
>
> I'm writing here to get some feedback on how to improve our wiki:
>
> https://github.com/chrissawer/The-Mutopia-Project/wiki/Setting-up-for-Contributions-via-GITHUB
>
> I usually try to avoid any merge commit in my pull requests. I think
> that it's all about rebasing instead of merging, right?
> It should be quite easy for us, I think, since we usually organize and
> book the files to be added/updated.
>
> Suggestions are welcomed.
> Thanks
> Federico
>
> ___
> Mutopia-discuss mailing list
> Mutopia-discuss@mutopiaproject.org
> http://lists.bcn.mythic-beasts.com/mailman/listinfo/mutopia-discuss
>
>
>   Thanks Javier, this new page was the missing bit!
> I've updated the main page of the wiki and added an "index" of the
> articles (even if there's an automatic list under Pages on the right).
>
> It seems that wiki links are better: - [[|]]
> https://help.github.com/articles/adding-links-to-wikis
>
> https://github.com/chrissawer/The-Mutopia-Project/wiki
>
>
> ___
> Mutopia-discuss mailing list
> Mutopia-discuss@mutopiaproject.org
> http://lists.bcn.mythic-beasts.com/mailman/listinfo/mutopia-discuss
>
___
Mutopia-discuss mailing list
Mutopia-discuss@mutopiaproject.org
http://lists.bcn.mythic-beasts.com/mailman/listinfo/mutopia-discuss

Re: [Mutopia-discuss] clean pull requests?

[Federico Bruni]

Il giorno mar 13 mag 2014 alle 23:09, Javier Ruiz-Alma 
 ha scritto:

Hi Federico,
Glen graciously added instructions on how to setup your github fork, 
and basic workflow involved in maintaining existing pieces in Mutopia 
using github.
He also a started a document to highlight LilyPond coding practices 
for new submissions to Mutopia, which enhance the maintainability 
moving forward.


Today, I drafted a new doc covering new submissions:
https://github.com/chrissawer/The-Mutopia-Project/wiki/Guidelines-for-new-score-submissions-using-github

Github has proven to be a great environment for code collaboration, 
and we welcome contributors using pull-requests.


Javier Ruiz-Alma



Thanks Javier, this new page was the missing bit!
I've updated the main page of the wiki and added an "index" of the 
articles (even if there's an automatic list under Pages on the right).


It seems that wiki links are better: - [[|]]
https://help.github.com/articles/adding-links-to-wikis

https://github.com/chrissawer/The-Mutopia-Project/wiki


___
Mutopia-discuss mailing list
Mutopia-discuss@mutopiaproject.org
http://lists.bcn.mythic-beasts.com/mailman/listinfo/mutopia-discuss

Re: [Mutopia-discuss] clean pull requests?

[Javier Ruiz-Alma]

Hi Federico,
Glen graciously added instructions on how to setup your github fork, and basic 
workflow involved in maintaining existing pieces in Mutopia using github.
He also a started a document to highlight LilyPond coding practices for new 
submissions to Mutopia, which enhance the maintainability moving forward.


Today, I drafted a new doc covering new submissions:
https://github.com/chrissawer/The-Mutopia-Project/wiki/Guidelines-for-new-score-submissions-using-github


Github has proven to be a great environment for code collaboration, and we 
welcome contributors using pull-requests.

Javier Ruiz-Alma
On Tuesday, May 13, 2014 8:29 AM, Federico Bruni  wrote:
 
I've just given a quick glance to the pull requests sent today by 
>ksnortum.
>I see a lot of merge commits which are unnecessary. I don't know how 
>this is sorted out when merging..
>
>I'm writing here to get some feedback on how to improve our wiki:
>https://github.com/chrissawer/The-Mutopia-Project/wiki/Setting-up-for-Contributions-via-GITHUB
>
>I usually try to avoid any merge commit in my pull requests. I think 
>that it's all about rebasing instead of merging, right?
>It should be quite easy for us, I think, since we usually organize and 
>book the files to be added/updated.
>
>Suggestions are welcomed.
>Thanks
>Federico
>
>___
>Mutopia-discuss mailing list
>Mutopia-discuss@mutopiaproject.org
>http://lists.bcn.mythic-beasts.com/mailman/listinfo/mutopia-discuss
>
>
>___
Mutopia-discuss mailing list
Mutopia-discuss@mutopiaproject.org
http://lists.bcn.mythic-beasts.com/mailman/listinfo/mutopia-discuss

[Mutopia-discuss] clean pull requests?

[Federico Bruni]

I've just given a quick glance to the pull requests sent today by 
ksnortum.
I see a lot of merge commits which are unnecessary. I don't know how 
this is sorted out when merging..

I'm writing here to get some feedback on how to improve our wiki:
https://github.com/chrissawer/The-Mutopia-Project/wiki/Setting-up-for-Contributions-via-GITHUB

I usually try to avoid any merge commit in my pull requests. I think 
that it's all about rebasing instead of merging, right?
It should be quite easy for us, I think, since we usually organize and 
book the files to be added/updated.

Suggestions are welcomed.
Thanks
Federico

___
Mutopia-discuss mailing list
Mutopia-discuss@mutopiaproject.org
http://lists.bcn.mythic-beasts.com/mailman/listinfo/mutopia-discuss