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
