Your link says "Merge is perfectly fine for managing your code." The only drawback it mentions is a more cluttered log. It has far stronger warnings about misusing rebase.
How could anyone read this conclusion 1. Merge works great, but creates lots of empty merge commits when you are working on a team. 2. Rebase keeps things tidy, but is destructive and potentially dangerous if you don’t know what you are doing. and not conclude that merge is better for non-experts? - Gordon Sent from my iPad On Apr 5, 2013, at 7:12 PM, "Gordon Smith" <gosm...@adobe.com<mailto:gosm...@adobe.com>> wrote: 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<mailto: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/
