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
