That's the point Alex... Any solve can resolve as a single commit or in a change set, and this decision, under what criterial it does? -- 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 6:02 PM, Alex Harui <aha...@adobe.com> wrote: > At minimum, if we can't decide on one particular practice, can we get a > better understanding of what problem is solved by a single commit in a > branch? Then those who are trying to decide what to do can make a better > decision. > > > On 3/27/13 9:36 AM, "Frédéric THOMAS" <webdoubl...@hotmail.com> wrote: > >> Another point Carlos, >> >>> this is really a matter of tastes. Each one should be happy with his way >>> of proceed >> >> What should I do a git wiki with the good practices if at the end everyone >> does what he wants, I guess we can try as written in the wiki for one month >> and if it doesn't fit we can change it (but really, I think everyone will be >> happy with it). >> >> Thanks, >> -Fred >> >> -----Message d'origine----- >> From: Frédéric THOMAS >> Sent: Wednesday, March 27, 2013 5:22 PM >> To: dev@flex.apache.org >> Subject: Re: [2/2] git commit: Merge branch 'FLEX-33349' into develop >> >> Yeah, for sure, it's your point of view and happily everyone's got one and >> not everyone the same, but from what I see from the current graph on the >> develop branch or the one gave by Jose plus the explanations you gave, I >> have the impression to see and hear "Why should I do simple when I can do >> complicated". >> >> If you look closely to the ASCII graph I wrote, you might have noticed there >> are no crossed lines, it's really linear, one commit/jira at time, I really >> maintain it is more readable and reflect more what the people really >> develops, there's no artificial forced merge. >> >> Thanks, >> -Fred >> >> -----Message d'origine----- >> From: Carlos Rovira >> Sent: Wednesday, March 27, 2013 4:03 PM >> To: dev@flex.apache.org >> Subject: Re: [2/2] git commit: Merge branch 'FLEX-33349' into develop >> >> IMHO this is hard to see, and even more for people outside or coming some >> time later in time, but that's only my opinion... I think we should not >> stand too much on these topics and going forward since this is really a >> matter of tastes. Each one should be happy with his way of proceed while >> making things properly since both ways are right. This is much more like >> trying to realize how to format code, each developer will do in its own >> way....put the bracket in the same line? in the next line?. I think we >> should be more interested in the overall GIT workflow that ensure that we >> all can share our contributions and make the repo safe of problems. >> >> >> >> 2013/3/27 Frédéric THOMAS <webdoubl...@hotmail.com> >> >>> It should have been like that even: >>> >>> * Merge branch ŒFLEX-33451¹ into develop [Fred] >>> * FLEX-33451: Fixed .gitignore [Fred] >>> * FLEX-33451: Tempora... [Fred] >>> * FLEX-33451: Fix TLF [Fred] >>> * FLEX-33349: Fix type error [Carlos] >>> * removed copy of empty.bundles... [Justin] >>> * FLEX-28946 committed patch... [Cyrill] >>> * Merge branch ŒFLEX-21066¹ into develop [Carlos] >>> * FLEX-21066: implemented remove item... [Carlos] >>> * FLEX-21066: add removeItemError... [Carlos] >>> * FLEX-21066: add removeItem to list... [Carlos] >>> * Merge branch ŒFLEX-33408¹ into develop [Carlos] >>> * ... >>> >>> I hope that will be display well. >>> >>> -Fred >>> >>> *From:* Jose Barragan <jose.barra...@codeoscopic.com> >>> *Sent:* Wednesday, March 27, 2013 1:26 PM >>> *To:* dev@flex.apache.org >>> *Subject:* Re: [2/2] git commit: Merge branch 'FLEX-33349' into develop >>> >>> Here's how it would Develop, after merging the branches of Charles and >>> Fred, as you can see, thereby properly appreciate the content of the two >>> applied Tickets. >>> However, Justin's commit b5da14a, is visually hidden under the branch of >>> Cyrill. >>> >>> Thanks, >>> -- >>> *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 11:13 AM, Frédéric THOMAS <webdoubl...@hotmail.com> >>> wrote: >>> >>> Having the rule of one commit doesn't generated an extra merge commit and >>> makes the log history more readable and because you know that corresponds >>> to 1 single task/jira/file, it's still easy to find it back without the >>> visual pollution of the extra useless merge commit. >>> >>> For the dictator-lieutenant model, we're not as big as linux kernel, maybe >>> one day, in between I wouldn't like to introduce hierarchy in an apache >>> model where it doesn't fit, anyway, look at what I said for the bugfix I >>> just shared, "I'll do the merge at the end" which means I'll re-write >>> commits in order, clean up what has to be clean if any, etc.., it's not >>> the >>> dictator-lieutenant model but a collaborative one which say as a lazy >>> consensus someone will merge/ clean up at the end, as you can see at the >>> end, no needs for a dictator model to do the same things as it is useless >>> to use a gun to kill a fly. >>> >>> Thanks, >>> -Fred >>> >>> -----Message d'origine----- From: Carlos Rovira >>> Sent: Wednesday, March 27, 2013 10:24 AM >>> To: dev@flex.apache.org >>> Subject: Re: [2/2] git commit: Merge branch 'FLEX-33349' into develop >>> >>> 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.apac >>> he.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 >>> >>> >>> >> >> > > -- > Alex Harui > Flex SDK Team > Adobe Systems, Inc. > http://blogs.adobe.com/aharui >
