Hi Carlos, If you could take the time to show an example where having a 1 commit branch helped you "gain control" that would help me and probably others understand the tradeoffs.
On 3/27/13 10:47 AM, "Carlos Rovira" <carlos.rov...@codeoscopic.com> wrote: > Hi Alex, > > as I said this is a matter of taste, but we are using git with huge > projects for months and when we are merging and generating releases and we > end wanting to easily see *all* branches to quickly see what we want to do, > without taking care if a branch is 1 commit or 10, since this make you gain > control of revert something if you need at some point in time. You end > having more control and people not involved in a particular development can > easily see what happened. > > Right now I think is difficult to see since we are starting in GIT, but as > GIT graph evolve we will see more complex representations and will be > difficult to see quickly the GIT history. As I pass for that *problem* > before, I already adopted the way to make always a branch although I have > only one commit, but again, I recognized that it's a matter of tastes and > it's difficult to sell the idea if you like not do it. > > > > 2013/3/27 Alex Harui <aha...@adobe.com> > >> I"m used to SVN's linear history. I like the fact that Git can show branch >> history, and like the idea that I can do multiple commits before pushing >> and >> each of those commits is clearly shown in the history. >> >> But if I don't want to show those multiple commits or I don't have multiple >> commits, my instinct would be to just make it a linear entry. I think >> Carlos is saying there is some advantage to not doing that, and I want to >> know what that advantage is. >> >> >> On 3/27/13 10:06 AM, "Jose Barragan" <jose.barra...@codeoscopic.com> >> wrote: >> >>> 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.ap >>>>>> ac >>>>>> 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://gi >>>>>> t- >>>>>> wip-us.apache.org/repos/asf/flex-sdk/tree/39fdf7fa> >>>>>> Diff: >>>>>> http://git-wip-us.apache.org/**repos/asf/flex-sdk/diff/**39fdf7fa< >> http://gi >>>>>> t- >>>>>> 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 >>>> >>> >> >> -- >> Alex Harui >> Flex SDK Team >> Adobe Systems, Inc. >> http://blogs.adobe.com/aharui >> >> > > > -- > 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
