> Unfortunately that won't prevent it. Please explain why not.
- Gordon Sent from my iPad On Apr 5, 2013, at 6:21 PM, "Michael A. Labriola" <labri...@digitalprimates.net> wrote: > Gordon and Justin, > >> I agree that it would be bad to edit 2 files, do a 'git pull' followed by a >> 'git status', and see changes to 200 files from other people mingling with >> your changes to 2. The simple way to prevent this is to commit your changes >> before pulling in other people's changes (I think). > > Unfortunately that won't prevent it. For now, it's more about just educating > everyone about merges. > > Read this (and the comments if you are brave). [1] What Fred was advocating > was a rebase workflow. What Gordon is proposing is mostly a merge workflow. > That latter can work, we use it often, but it puts the onus on the developer > doing the merge. Incidentally, this is why is most larger open source > projects... see linux (or even what we did on FlexUnit in git) have a very > few number of people who knew git well that managed the actual develop and > master branches. > > The rest of the community happily worked from their own forks (which is > basically just a server side copy of git all to your own) and just pulled in > changes from develop, they didn't push to develop. That was the question I > was originally asking Fred as to if there was a technical reason that we were > setup this way. Incidentally, Fred did an excellent job on the wiki pages and > making his case. > > I understand why everyone can see git as a pain right now. I really do. > Ultimately the active committers on this list need to decide the correct > route for the project. From my experience, this is the best analogy I can > give. Please indulge me one last time. > > SVN was like a nail and everyone got good at using a hammer to put that nail > into the wall. Git is a screw. When you start, it's natural to try to pound > the screw into the wall the same way you did a nail. You can make it work, > but it will seem cumbersome and inelegant compared to the ease of the nail. > You won't see any advantages and it won't get any better, although you can > make it work. If, however, you can begin to see that the screw works > differently (and btw, that's the big thing git and SVN are honestly night and > day in how they work and their workflow) and begin carrying the right tool, > soon you can see that the screw has some advantages. It doesn't replace a > nail but for certain applications it's much more useful. Look at the success > of open source projects on github, linux and many others and I promise, we > aren't all crazy. There are growing pains, but they are not insurmountable. > > I personally wish we had more of a github fork model here where a couple of > people have the keys to the castle. To be honest, that's what I was > envisioning when I voted for git. It may not be possible at this point or > ever, but the result is putting the onus on everyone learning more about git > than they might otherwise need and having a miserable experience. So, read my > link. Ask questions and I will answer here whenever possible. > > Mike > > [1] > http://www.jarrodspillers.com/2009/08/19/git-merge-vs-git-rebase-avoiding-rebase-hell/ >
