+1

On Fri, Jan 25, 2019, 1:29 PM Deepak Dixit <deepak.di...@hotwax.co wrote:

> Looks good Michael.
>
> Thanks & Regards
> --
> Deepak Dixit
>
>
>
> On Fri, Jan 25, 2019 at 1:54 PM Michael Brohl <michael.br...@ecomify.de>
> wrote:
>
> > Hi everyone,
> >
> > thank you all for your feedback. It seems that we have consensus to
> > switch over to Git.
> >
> > I'll prepare a Wiki page to start documentation on the processes and the
> > needed steps to make the switch. I'll take over the topics mentioned in
> > this thread (Taher's initial proposed workflow, Jacques notes about
> > build scripts, auto-props etc.).
> >
> > We should then finish the process description, maybe discuss and decide
> > upon and then plan the technical switch.
> >
> > Makes sense?
> >
> > Best regards,
> >
> > Michael
> >
> >
> >
> > Am 23.01.19 um 07:37 schrieb Jacopo Cappellato:
> > > +1 for Git!
> > >
> > > Jacopo
> > >
> > > On Sat, Jan 12, 2019 at 1:01 PM Michael Brohl <
> michael.br...@ecomify.de>
> > > wrote:
> > >
> > >> Hi all,
> > >>
> > >> I'd like to revive this discussion again.
> > >>
> > >> Personally, I am now working with git for a few years and almost all
> > >> customer and company related projects have moved to git over time. In
> > >> the beginning, I found git complicated and less straight forward, a
> bit
> > >> like Adrian mentioned in [1]. But once I have understood the main
> > >> principles and get used to it, I won't like to switch back to svn ever
> > >> since.
> > >>
> > >> In my opinion, using git would make things much easier for
> > >> collaboration. Taher thoroughly described them in the inital thread
> > >> message.
> > >>
> > >> An important point for me would be that we could prevent premature
> > >> commits just to get things to be tested. Features which take some time
> > >> to be worked on or tested can be in separate branches which can be
> > >> updated with the main branch constantly.
> > >>
> > >> So, from my point of view, we should again have a disussion and/or
> vote
> > >> to see if the overall opinions have changed and if we could move to
> git.
> > >>
> > >> Thanks,
> > >>
> > >> Michael
> > >>
> > >>
> > >> [1] http://markmail.org/message/m4z5b5qevqx7n6u7
> > >>
> > >> Am 24.10.15 um 10:23 schrieb Taher Alkhateeb:
> > >>> Hello Everyone,
> > >>>
> > >>> I refer to the discussion about moving to git initiated by Hans
> Bakker
> > >> back in April. After a long, long discussion followed by a vote the
> > >> community agreed that we should develop a more elaborate and formal
> > >> workflow to vote on, as the initial vote was not detailed enough.
> Based
> > on
> > >> that, I have proposed a workflow to see if people are interested in
> it.
> > But
> > >> the topic just slowly died out.
> > >>> The links to both threads are listed below. I understand that there
> was
> > >> a lot of interest in the community as the thread was really long. I
> > would
> > >> like to revive the discussion and see if people are still interested
> in
> > >> implementing / amending the proposed workflow if they find it
> appealing.
> > >>> discussion and vote thread :
> > >>
> >
> http://ofbiz.markmail.org/message/ldo77qz34kte4gat?q=move+to+git+from:%22Hans+Bakker%22+list:org.apache.ofbiz.dev&page=1
> > >>> workflow proposition thread :
> > >>
> > http://ofbiz.markmail.org/message/nkthnbsgt37orynu?q=git+commit+workflow
> > >>> Taher Alkhateeb
> > >>> ----- Original Message -----
> > >>>
> > >>> From: "Taher Alkhateeb" <slidingfilame...@gmail.com>
> > >>> To: dev@ofbiz.apache.org
> > >>> Sent: Wednesday, 24 June, 2015 5:25:31 PM
> > >>> Subject: Re: git commit workflow for ofbiz
> > >>>
> > >>>
> > >>> Hi Jacques,
> > >>>
> > >>> Very good read, thank you for sharing.
> > >>>
> > >>> The person who wrote complaining about gitflow (I think Adam Ruka)
> > makes
> > >> a good point. He prefers linear to branched history. I do not mind
> > branched
> > >> history myself as I know how to navigate it but to each his own.
> Either
> > >> way, The workflow can be accomplished the way he suggested by rebasing
> > >> rather than merging the history and making a few other changes like
> > >> dropping "develop". It is up to community to decide, and git is
> flexible
> > >> enough to accommodate any model.
> > >>> Taher Alkhateeb
> > >>>
> > >>> ----- Original Message -----
> > >>>
> > >>> From: "Jacques Le Roux" <jacques.le.r...@les7arts.com>
> > >>> To: dev@ofbiz.apache.org
> > >>> Sent: Wednesday, 24 June, 2015 4:19:42 PM
> > >>> Subject: Re: git commit workflow for ofbiz
> > >>>
> > >>> Le 24/06/2015 14:06, Jacques Le Roux a écrit :
> > >>>> If you get a chance to read these articles I highly recommend them
> > >>>>
> > >>>>
> > >>
> >
> http://www.alwaysagileconsulting.com/organisation-pattern-trunk-based-development/
> > >>> Of course don't miss
> > >>
> >
> http://www.alwaysagileconsulting.com/organisation-antipattern-release-feature-branching/
> > >>> Jacques
> > >>>
> > >>>> http://endoflineblog.com/gitflow-considered-harmful
> > >>>> http://endoflineblog.com/follow-up-to-gitflow-considered-harmful
> > >>>>
> > >>>> Jacques
> > >>>>
> > >>>>
> > >>>> Le 12/05/2015 19:28, Adam Heath a écrit :
> > >>>>> Nice. This is quite thorough. There is an option missing. SVN
> > >> committers who use git offline. In this case, their changes can be
> > >> published as
> > >>>>> primary SVN branches, for collaboration.. See OFBIZ-6271 in JIRA,
> and
> > >> as an SVN branch, for an example.
> > >>>>> I've read through most of what follows, and am in agreement, but
> I'm
> > >> dealing with hardware problems, so I need to let it sink in first.
> > >>>>> On 05/12/2015 04:43 AM, Taher Alkhateeb wrote:
> > >>>>>> Hi everyone,
> > >>>>>>
> > >>>>>> This email refers to the thread for voting to move to git (link at
> > >> bottom) in which the vote decision was to delay and elaborate on the
> > >> workflow
> > >>>>>> first. I am not well versed in ASF guidelines and appreciate any
> > help
> > >> and feedback and also please note some of the below is my opinion and
> > not
> > >>>>>> necessarily 100% factual.
> > >>>>>>
> > >>>>>> ## First, identified problems
> > >>>>>>
> > >>>>>> 1. patches can quickly be outdated if not applied quickly
> > >>>>>> 2. big patches are hard to audit and not desired nor preferred and
> > It
> > >> is hard to break big patches to smaller ones because if any of those
> > patches
> > >>>>>> is outdated or modified then everything needs to be re-patched
> > >>>>>> 3. to collaborate with other people (non-committers) freely on big
> > >> features, we need a separate branch. On svn this is lengthy and
> heavily
> > >>>>>> controlled. If we create a git repository then we need to
> constantly
> > >> update from svn and merge . Another solution is to clone the ofbiz
> > read-only
> > >>>>>> git repository but then there are some patch issues to convert
> them
> > >> to clean svn patches (I faced a few including things like white space)
> > >>>>>> 4. a lot of _local_ offline freedom to branch, merge, commit,
> share
> > >> and experiment cannot be easily done without initiating a local git
> > >> repository
> > >>>>>> which triggers the other problems identified above.
> > >>>>>> 6. There are too many public branches in the repositoy. Some are
> not
> > >> active nor complete and quite old
> > >>>>>> ## Second, how does git provide solutions
> > >>>>>>
> > >>>>>> So, adopting git in relation to the above mentioned problems
> solves
> > >> them as follows:
> > >>>>>> 1. even if a patch gets outdated, I can easily recreate it by
> > >> switching to a branch that I created and has the work (e.g.
> > OFBIZ-12345),
> > >> merging
> > >>>>>> everything from trunk and re-patching
> > >>>>>> 2. to allow for proper feedback by community, a pull request can
> > >> replace a big patch and that request can hold an X amount of commits
> > each
> > >> with
> > >>>>>> its own message and diff details. If changes happen to any of the
> > >> commits, then reconciling that into the code base is minor, you just
> > branch
> > >>>>>> again, do it, and merge. Furthermore, I suggest to follow the
> > >> guidelines which recommend rebasing before pushing to a shared
> > repository
> > >> to keep a
> > >>>>>> nice linear history as much as possible as shown here ->
> > >> https://git-wip-us.apache.org/docs/committer-practices.html
> > >>>>>> 3. large features can be done in a remote repository in github or
> > >> bitbucket with pull requests when complete and ready for review.
> > >>>>>> 4. the issue is immediately solved with git which is not only
> local
> > >> but much, much faster
> > >>>>>> 6. We do not need to pollute the main repository with branches if
> we
> > >> decide on a distributed model like git with remote repositories to
> > >> contribute
> > >>>>>> to the project with pull requests.
> > >>>>>>
> > >>>>>> ## Third, proposed workflow
> > >>>>>>
> > >>>>>> I will make a distinction between small features / bug fixes and
> > >> large features.
> > >>>>>> ### small features
> > >>>>>>
> > >>>>>> Small features follow the exact same workflow that currently
> exists
> > >> in svn. You do your work, diff it, and attach the patch to a JIRA and
> > >> request
> > >>>>>> a commit from one of the committers.
> > >>>>>>
> > >>>>>> ### large features
> > >>>>>>
> > >>>>>> For large features usually multiple people need to collaborate on
> a
> > >> separate branch. Here is where git shines and the distributed model
> > kicks
> > >> in:
> > >>>>>> 1. A JIRA is created for a large feature
> > >>>>>> 2. The team (not necessarily having a committer) creates a remote
> > >> repository which itself may have many branches with the master branch
> > >> having all
> > >>>>>> the work agreed upon and merged (actually, rebased)
> > >>>>>> 3. The collaboration for this branch happens in the JIRA including
> > >> discussions, comments, and even links to the commits etc ...
> > >>>>>> 4. A request is made to a committer to make a pull request from
> the
> > >> repository after reaching a certain milestone with consensus from the
> > >>>>>> community of course
> > >>>>>> 5. Here, for extra safety, the branch model may have a trunk and a
> > >> develop branches. Everything is pulled to the develop branch and
> > trickles
> > >> down
> > >>>>>> to the master branch after thorough and proper testing.
> > >>>>>>
> > >>>>>> The above workflow can also adhere to the now famous Vincent
> > Driessen
> > >> git branching model found here ->
> > >>>>>> http://nvie.com/posts/a-successful-git-branching-model/
> > >>>>>>
> > >>>>>> I am not sure whether this proposal is enough or correct so I
> > >> appreciate your guidance and feedback to fix whatever needs fixing.
> > >>>>>> Taher Alkhateeb
> > >>>>>>
> > >>>>>> original voting thread:
> > >>>>>>
> > >>
> >
> http://ofbiz.markmail.org/search/?q=move%20to%20git#query:move%20to%20git+page:1+mid:p62ofojcbb3oyoi4+state:results
> > >>>
> > >>
> >
> >
>

Reply via email to