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
