On 4/5/13 7:22 PM, "Gordon Smith" <gosm...@adobe.com> wrote:
>
> 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?
Because, IIUC, most of the work we do is better suited for rebase. SVN
essentially did a rebase for you. The difference is when you start pulling
stuff from other public branches, not from the local branch you made when
you started to make some changes.
I could be wrong, but I'm pretty sure that most of the complexity occurs
when you start sharing code with other committers before its gets "checked
in". 99% of the time we aren't going to do that and a simple SVN-like
approach seems to be working for me. At least, nobody has gotten on my case
for screwing up history. But please review my checkins on flex-asjs and
flex-falcon and correct me if I'm doing something wrong. I am using
--rebase 100% of the time so far because I don't think the series of changes
are related enough to deserve a "branch" in the history.
>
> - 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-reba
> se-hell/
>
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
