Sorry for missing link: Git Patterns and Anti-Patterns: Scaling from Workgroup to Enterprise<http://refcardz.dzone.com/assets/download/refcard/bf3d79c7ce6019dc5ff28cf76c3f48db/rc178-010d-git-patterns-antipatterns_1.pdf> --> http://refcardz.dzone.com/assets/download/refcard/bf3d79c7ce6019dc5ff28cf76c3f48db/rc178-010d-git-patterns-antipatterns_1.pdf
On Wed, Mar 27, 2013 at 10:41 AM, Jose Barragan < jose.barra...@codeoscopic.com> wrote: > +1 with Carlos > > check it out this: Git Patterns and Anti-Patterns: Scaling from > Workgroup to > Enterprise<http://refcardz.dzone.com/assets/download/refcard/bf3d79c7ce6019dc5ff28cf76c3f48db/rc178-010d-git-patterns-antipatterns_1.pdf> > -- > *Jose Barragan* > *Chief **Software Architect* > Codeoscopic Madrid > C/. Infanta Mercedes, 92. > Planta 5. 505. > 28020 Madrid. > Tel.: +34 912 94 80 80 > > On Mar 27, 2013, at 10:35 AM, Jose Barragan <jose.barra...@codeoscopic.com> > wrote: > > +1 with Carlos > <rc178-010d-git-patterns-antipatterns_1.pdf> > > -- > *Jose Barragan* > *Chief **Software Architect* > Codeoscopic Madrid > C/. Infanta Mercedes, 92. > Planta 5. 505. > 28020 Madrid. > Tel.: +34 912 94 80 80 > > On Mar 27, 2013, at 10:24 AM, Carlos Rovira <carlos.rov...@codeoscopic.com> > wrote: > > Hi Frederic, > > in our experience working with GIT we saw that was extremely helpful to > have visual track of each set of commits that are a single fix, > functionality, feature or whatever, since you can always operate and have > much control as branches grow and ramifies. In the particular case you > point (single commit - flat history) it's a matter of tastes but making it > flat for this particular case makes you lost visibility as GIT workflow > evolve over time. Right now we could make it flat (at this point of > simplicity), but I recommend not to do it since in few months we should > expect more complex GIT graphs and this kind of loops will help to see > others what historically happen. > > Apache Flex is so huge and modular and over time we should organize in a > way that make us possible to plan huge releases with lots of modules, > changes and consistence between pieces. We are right now at the very > beginning trying to get the basic management and functionality but as > people will understand the full potential of the tool and the kind of > thinks we can now do, things will complicate. As we discussed in other > thread some weeks ago, I suspect that we will end in an > "dictator-lieutenant-apache" model (as we talked with Beltran the apache > part is that decisions must be consolidated in this list to adopt such > model), since it's what I see in other big open source projects where sub > teams are organized in repositories and they commit in such repositories > while the "lieutenant" assemble the final "module" (this happen in the same > way all the way to root until reach the "dictator"). As we said, if we end > in this model, the apache way will be less restricted in repo permissions > and more conducted by the list where people will assign the tasks to a > single person. > > > > > > 2013/3/27 Frédéric THOMAS <webdoubl...@hotmail.com> > > Hi Carlos, > > This merge you did make me think I didn't talk about this case on the wiki > [1], so I updated it, in short, while it is good to start a branch as you > did for a new jira ticket and as you may don't know the final number of > commits you will have at the end, once it is the time to merge, you know > the number of commits you did, if you realize you've got only one, it is > better to do a 'git rebase <my_branch>' instead of a 'git merge --no-ff > <my_branch>, the reason behind that is that you can avoid the extra merge > commit, practically nothing change, except you will have a flat history > which is what we want for only one commit and it could be reverse/reset the > same if needed. > > Thanks, > -Fred > > [1] https://cwiki.apache.org/**confluence/display/FLEX/Good+** > vs+Bad+Git+usage< > https://cwiki.apache.org/confluence/display/FLEX/Good+vs+Bad+Git+usage> > > -----Message d'origine----- From: carlosrov...@apache.org > Sent: Wednesday, March 27, 2013 3:12 AM > To: comm...@flex.apache.org > Subject: [2/2] git commit: Merge branch 'FLEX-33349' into develop > > Merge branch 'FLEX-33349' into develop > > * FLEX-33349: > Fix TypeError #1009 happening in dataProviderRefreshed() of List.as after > refreshing the dataProvider of Combobox. > > > Project: > http://git-wip-us.apache.org/**repos/asf/flex-sdk/repo<http://git-wip-us.apache.org/repos/asf/flex-sdk/repo> > Commit: http://git-wip-us.apache.org/**repos/asf/flex-sdk/commit/** > 39fdf7fa <http://git-wip-us.apache.org/repos/asf/flex-sdk/commit/39fdf7fa> > Tree: > http://git-wip-us.apache.org/**repos/asf/flex-sdk/tree/**39fdf7fa<http://git-wip-us.apache.org/repos/asf/flex-sdk/tree/39fdf7fa> > Diff: > http://git-wip-us.apache.org/**repos/asf/flex-sdk/diff/**39fdf7fa<http://git-wip-us.apache.org/repos/asf/flex-sdk/diff/39fdf7fa> > > Branch: refs/heads/develop > Commit: 39fdf7fa81329fa60eb95efc374375**a901c34d3d > Parents: 6282657 5ca083e > Author: Carlos Rovira <carlos.rov...@gmail.com> > Authored: Wed Mar 27 03:12:08 2013 +0100 > Committer: Carlos Rovira <carlos.rov...@gmail.com> > Committed: Wed Mar 27 03:12:08 2013 +0100 > > ------------------------------**------------------------------**---------- > .../projects/spark/src/spark/**components/List.as | 23 > +++++++++++---- > 1 files changed, 17 insertions(+), 6 deletions(-) > ------------------------------**------------------------------**---------- > > > > > > -- > Carlos Rovira > Director de Tecnología > M: +34 607 22 60 05 > F: +34 912 94 80 80 > http://www.codeoscopic.com > http://www.directwriter.es > http://www.avant2.es > > > >
