Correction: "Why should I do" instead of "What should I do".
Finally, you was one of the more talkative person about Git before the
migration, I would have supposed you wrote something for Git on the wiki,
good practices, etc... but it didn't happen and from what I read from you
now, I'm realizing that's finally not as bad as that.
But, that's only my point of you, maybe people here will like to see you
take the bull by the horns and drive us with Git.
Thanks,
-Fred
-----Message d'origine-----
From: Frédéric THOMAS
Sent: Wednesday, March 27, 2013 5:36 PM
To: dev@flex.apache.org
Subject: Re: [2/2] git commit: Merge branch 'FLEX-33349' into develop
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.apache.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
--
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
