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 <ksnor...@gmail.com> 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 <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
