Re: [Mutopia-discuss] clean pull requests?
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 glenl@gmail.com wrote: On Tue, May 13, 2014 at 5:41 PM, Knute Snortum ksnor...@gmail.com 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?
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 ksnor...@gmail.com 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 glenl@gmail.com wrote: On Tue, May 13, 2014 at 5:41 PM, Knute Snortum ksnor...@gmail.com 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?
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?
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 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?
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 f...@inventati.org 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 workflowhttps://github.com/chrissawer/The-Mutopia-Project/wiki/Setting-up-for-Contributions-via-GITHUB involved in maintaining existing pieces in Mutopia using github. He also a started a document to highlight LilyPond coding practiceshttps://github.com/chrissawer/The-Mutopia-Project/wiki/Best-practices-for-new-submissions 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 f...@inventati.org 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?
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 glenl@gmail.com 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 f...@inventati.orgwrote: 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 workflowhttps://github.com/chrissawer/The-Mutopia-Project/wiki/Setting-up-for-Contributions-via-GITHUB involved in maintaining existing pieces in Mutopia using github. He also a started a document to highlight LilyPond coding practiceshttps://github.com/chrissawer/The-Mutopia-Project/wiki/Best-practices-for-new-submissions 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 f...@inventati.org 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
