flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Frédéric THOMAS <webdoubl...@hotmail.com>
Subject Re: [2/2] git commit: Merge branch 'FLEX-33349' into develop
Date Wed, 27 Mar 2013 13:10:13 GMT
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 
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 <webdoublefx@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 <webdoublefx@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: carlosrovira@apache.org
    Sent: Wednesday, March 27, 2013 3:12 AM
    To: commits@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.rovira@gmail.com>
    Authored: Wed Mar 27 03:12:08 2013 +0100
    Committer: Carlos Rovira <carlos.rovira@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 


Mime
  • Unnamed multipart/related (inline, None, 0 bytes)
View raw message