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
