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
