"If you and your team are not familiar with, or don’t understand the intricacies of rebase, then you probably shouldn’t use it. In this context, always merge is the safest option." That's what happen here despite my efforts to explain when and how to use "rebase" over "merge" (see the wiki) and my first main reason of being bored committing onto this repo over common stuffs.
Frédéric THOMAS > Subject: Re: Hi, about my "experimental/VF2JS" branch > From: jose.barra...@codeoscopic.com > Date: Thu, 10 Jul 2014 16:14:50 +0200 > To: dev@flex.apache.org > > Hi Justin, > > Under the new light from this article, I have anything else to say. > > Clearly I’m a rebase guy, over all, after suffering at our company the > extremely complexity that we reached by using only the merge way. > > Well, as I told to @Erik, if my proposal didn't like it or didn't was > candidate for adopt it, I'll delete it from repository asap. > > Thanks for your attention. > > Best regards, > ______________________ > Jose Barragan > Senior Software Engineer > Codeoscopic > +34 912 94 80 80 > http://www.codeoscopic.com > > On 10 Jul 2014, at 15:37, Justin Mclean <jus...@classsoftware.com> wrote: > > > Hi, > > > >> Nothing is really wrong there, is just for an philosophical criteria based > >> on best practices of git. > > > > Sorry but iMO it's not best practices, its just that a vocal group of git > > users think this it's the way to do things(tm) but other git users think > > otherwise. We also need to remember that have a central repo, need to apply > > with the Apache way of doing things and that can sometimes be at time odds > > with the git (or github) way of doing things. IMO Apache values > > traceability over a "clean" history. > > > > A good article about the pro and cons of merge and rebase can be found here > > [1], it's interesting to note the Atlasssian approach. > > > > Thanks, > > Justin > > > > 1. http://blogs.atlassian.com/2013/10/git-team-workflows-merge-or-rebase/ > > >
