Re: git commit workflow for ofbiz

[Jacques Le Roux <ja...@les7arts.com>]

If you get a chance to read these articles I highly recommend them

http://www.alwaysagileconsulting.com/organisation-pattern-trunk-based-development/

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
>>
>
>

Re: git commit workflow for ofbiz

[Taher Alkhateeb <sl...@gmail.com>]

+1

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

> Looks good Michael.
>
> Thanks & Regards
> --
> Deepak Dixit
>
>
>
> On Fri, Jan 25, 2019 at 1:54 PM Michael Brohl <mi...@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.brohl@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" <sl...@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" <ja...@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
> > >>>
> > >>
> >
> >
>

Re: git commit workflow for ofbiz

[Deepak Dixit <de...@hotwax.co>]

Looks good Michael.

Thanks & Regards
--
Deepak Dixit



On Fri, Jan 25, 2019 at 1:54 PM Michael Brohl <mi...@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 <mi...@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" <sl...@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" <ja...@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
> >>>
> >>
>
>

Re: git commit workflow for ofbiz

[Jacques Le Roux <ja...@les7arts.com>]

+1

Jacques

Le 25/01/2019 à 09:24, Michael Brohl a écrit :
> 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 <mi...@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" <sl...@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" <ja...@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
>>>>
>>>
>

Re: git commit workflow for ofbiz

[Michael Brohl <mi...@ecomify.de>]

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 <mi...@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" <sl...@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" <ja...@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
>>>
>>

Re: git commit workflow for ofbiz

[Jacopo Cappellato <ja...@hotwaxsystems.com>]

+1 for Git!

Jacopo

On Sat, Jan 12, 2019 at 1:01 PM Michael Brohl <mi...@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" <sl...@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" <ja...@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
> >>>>
> >>>
> >
> >
>
>

Re: git commit workflow for ofbiz

[Deepak Nigam <de...@gmail.com>]

+1 for Git.

Thanks & Regards
--
Deepak Nigam
HotWax Systems.Pvt. Ltd

On Mon, Jan 14, 2019 at 9:53 AM Yashwant Dhakad <
yashwant.dhakad@hotwaxsystems.com> wrote:

> +1 for Git
>
> Thanks & Regards
> --
> Yashwant Dhakad
>
>
> On Sun, Jan 13, 2019 at 1:27 AM Taher Alkhateeb <
> slidingfilaments@gmail.com>
> wrote:
>
> > It's awesome to revive this discussion Michael. +1 of course.
> >
> > We need to think practically of our workflows though and whether we
> > want a linear vs non-linear history model. I prefer the latter to
> > allow proper decentralized workflows but it's up to everyone here to
> > decide. I think the overall process is described thoroughly and we can
> > adhere to it for the most part.
> >
> > On Sat, Jan 12, 2019 at 9:35 PM Deepak Dixit <de...@hotwax.co>
> > wrote:
> > >
> > > We are using git since long and it's a great tool for collaboration.
> > > It has distributed version control system so you don't need an internet
> > > connection to view history and branch switching.
> > >
> > > Thanks Taher for nicly describing it.
> > >
> > > +1 for Git.
> > >
> > > Thanks & Regards
> > > --
> > > Deepak Dixit
> > >
> > >
> > >
> > > On Sat, Jan 12, 2019 at 11:54 PM Aditya Sharma <
> > > aditya.sharma@hotwaxsystems.com> wrote:
> > >
> > > > +1 for Git
> > > >
> > > > Thanks and Regards,
> > > > Aditya Sharma
> > > >
> > > > On Sat, Jan 12, 2019, 9:06 PM Suraj Khurana <suraj.khurana@hotwax.co
> > > > wrote:
> > > >
> > > > > +1 to move from SVN to Git.
> > > > >
> > > > > --
> > > > > Best Regards,
> > > > > Suraj Khurana
> > > > > Technical Consultant
> > > > >
> > > > > On Sat, Jan 12, 2019 at 7:12 PM Mathieu Lirzin <
> > > > mathieu.lirzin@nereide.fr>
> > > > > wrote:
> > > > >
> > > > > > Hello Michael,
> > > > > >
> > > > > > Michael Brohl <mi...@ecomify.de> writes:
> > > > > >
> > > > > > > I'd like to revive this discussion again.
> > > > > >
> > > > > > Do we still need to discuss it?  If the response is not obviously
> > “yes
> > > > > > we should move to Git” now that Git has become ubiquitous and
> that
> > SVN
> > > > > > is a moribund tool, then this community has a serious problem.
> :-)
> > > > > >
> > > > > > Joke aside I think the question should rather be:
> > > > > >
> > > > > >    Is there anyone here opposing to the move from SVN to Git?
> > > > > >
> > > > > > Thanks for reviving this topic!
> > > > > >
> > > > > > --
> > > > > > Mathieu Lirzin
> > > > > > GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37
> > > > > >
> > > > >
> > > >
> >
>

Re: git commit workflow for ofbiz

[Yashwant Dhakad <ya...@hotwaxsystems.com>]

+1 for Git

Thanks & Regards
--
Yashwant Dhakad


On Sun, Jan 13, 2019 at 1:27 AM Taher Alkhateeb <sl...@gmail.com>
wrote:

> It's awesome to revive this discussion Michael. +1 of course.
>
> We need to think practically of our workflows though and whether we
> want a linear vs non-linear history model. I prefer the latter to
> allow proper decentralized workflows but it's up to everyone here to
> decide. I think the overall process is described thoroughly and we can
> adhere to it for the most part.
>
> On Sat, Jan 12, 2019 at 9:35 PM Deepak Dixit <de...@hotwax.co>
> wrote:
> >
> > We are using git since long and it's a great tool for collaboration.
> > It has distributed version control system so you don't need an internet
> > connection to view history and branch switching.
> >
> > Thanks Taher for nicly describing it.
> >
> > +1 for Git.
> >
> > Thanks & Regards
> > --
> > Deepak Dixit
> >
> >
> >
> > On Sat, Jan 12, 2019 at 11:54 PM Aditya Sharma <
> > aditya.sharma@hotwaxsystems.com> wrote:
> >
> > > +1 for Git
> > >
> > > Thanks and Regards,
> > > Aditya Sharma
> > >
> > > On Sat, Jan 12, 2019, 9:06 PM Suraj Khurana <suraj.khurana@hotwax.co
> > > wrote:
> > >
> > > > +1 to move from SVN to Git.
> > > >
> > > > --
> > > > Best Regards,
> > > > Suraj Khurana
> > > > Technical Consultant
> > > >
> > > > On Sat, Jan 12, 2019 at 7:12 PM Mathieu Lirzin <
> > > mathieu.lirzin@nereide.fr>
> > > > wrote:
> > > >
> > > > > Hello Michael,
> > > > >
> > > > > Michael Brohl <mi...@ecomify.de> writes:
> > > > >
> > > > > > I'd like to revive this discussion again.
> > > > >
> > > > > Do we still need to discuss it?  If the response is not obviously
> “yes
> > > > > we should move to Git” now that Git has become ubiquitous and that
> SVN
> > > > > is a moribund tool, then this community has a serious problem.  :-)
> > > > >
> > > > > Joke aside I think the question should rather be:
> > > > >
> > > > >    Is there anyone here opposing to the move from SVN to Git?
> > > > >
> > > > > Thanks for reviving this topic!
> > > > >
> > > > > --
> > > > > Mathieu Lirzin
> > > > > GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37
> > > > >
> > > >
> > >
>

Re: git commit workflow for ofbiz

[Pritam Kute <pr...@hotwaxsystems.com>]

+1 for Git.

Thanks, Michael for reviving this discussion.

Regards
--
Pritam Kute

On Wed, Jan 16, 2019 at 3:30 PM Taher Alkhateeb <sl...@gmail.com>
wrote:

> Hi Jacques, I know you are a GUI fan, and for that I recommend this
> tool https://git-cola.github.io
>
> Make sure to install all requirements for a full enjoyable experience
> including viewing the history visually and whatnot
>
> On Wed, Jan 16, 2019 at 12:56 PM Jacques Le Roux
> <ja...@les7arts.com> wrote:
> >
> > Hi,
> >
> > We have some tasks to do (like revert and merge scripts) but I see no
> problems with that.
> >
> > Apart that I have to think a bit more about the workflow (I guess
> Taher's proposition should be fine)
> >
> > I must though say that you will certainly see a slow-down on my side.
> I'm used to a bunch of svn tools I use and will have to find similar for
> Git. I
> > already use TortoiseGit for 5 years so it should not be a big deal...
> >
> > Jacques
> >
> > Le 15/01/2019 à 07:31, Swapnil Mane a écrit :
> > > +1 for using Git.
> > > Personally, my experience is also very good with Git.
> > >
> > >
> > > - Best Regards,
> > > Swapnil M Mane
> > >
> > > On Mon, Jan 14, 2019 at 2:05 PM Nicolas Malin <
> nicolas.malin@nereide.fr>
> > > wrote:
> > >
> > >> On 12/01/2019 20:56, Taher Alkhateeb wrote:
> > >>> It's awesome to revive this discussion Michael. +1 of course.
> > >>>
> > >>> We need to think practically of our workflows though and whether we
> > >>> want a linear vs non-linear history model. I prefer the latter to
> > >>> allow proper decentralized workflows but it's up to everyone here to
> > >>> decide. I think the overall process is described thoroughly and we
> can
> > >>> adhere to it for the most part.
> > >> We can easily switch from svn to git without change own commit process
> > >> on first time by patch application.
> > >>
> > >> If a commiter want use merge feature, the squash function simulate the
> > >> application patch.
> > >>
> > >> So no opposite to move with this few remark
> > >>
> > >> Nicolas
> > >>
> > >>
>

Re: git commit workflow for ofbiz

[Jacques Le Roux <ja...@les7arts.com>]

Something else that we will need to do:

The equivalent of  svn:auto-props properties on server.
Something we will need to not forget when we will switch to Git: https://help.github.com/articles/dealing-with-line-endings/#per-repository-settings

Jacques

Le 16/01/2019 à 13:04, Jacques Le Roux a écrit :
> Thanks Taher,
>
> I'm already well used to TortoiseGit and tried before a couple of others but I prefer it (because I also use TortoiseSvn for 14 years). I have also 
> Git installed in Eclipse, there are few stuff that I like there.
>
> I also often use Git Bash and when really necessary (never happened so far with Git) turn to my Ubuntu VM.
>
> BTW we will also have to change the buildbot script, but that should be easy, only the repos to change.
>
> @All, any other things in mind we should change?
>
> Jacques
>
> Le 16/01/2019 à 11:00, Taher Alkhateeb a écrit :
>> Hi Jacques, I know you are a GUI fan, and for that I recommend this
>> tool https://git-cola.github.io
>>
>> Make sure to install all requirements for a full enjoyable experience
>> including viewing the history visually and whatnot
>>
>> On Wed, Jan 16, 2019 at 12:56 PM Jacques Le Roux
>> <ja...@les7arts.com> wrote:
>>> Hi,
>>>
>>> We have some tasks to do (like revert and merge scripts) but I see no problems with that.
>>>
>>> Apart that I have to think a bit more about the workflow (I guess Taher's proposition should be fine)
>>>
>>> I must though say that you will certainly see a slow-down on my side. I'm used to a bunch of svn tools I use and will have to find similar for Git. I
>>> already use TortoiseGit for 5 years so it should not be a big deal...
>>>
>>> Jacques
>>>
>>> Le 15/01/2019 à 07:31, Swapnil Mane a écrit :
>>>> +1 for using Git.
>>>> Personally, my experience is also very good with Git.
>>>>
>>>>
>>>> - Best Regards,
>>>> Swapnil M Mane
>>>>
>>>> On Mon, Jan 14, 2019 at 2:05 PM Nicolas Malin <ni...@nereide.fr>
>>>> wrote:
>>>>
>>>>> On 12/01/2019 20:56, Taher Alkhateeb wrote:
>>>>>> It's awesome to revive this discussion Michael. +1 of course.
>>>>>>
>>>>>> We need to think practically of our workflows though and whether we
>>>>>> want a linear vs non-linear history model. I prefer the latter to
>>>>>> allow proper decentralized workflows but it's up to everyone here to
>>>>>> decide. I think the overall process is described thoroughly and we can
>>>>>> adhere to it for the most part.
>>>>> We can easily switch from svn to git without change own commit process
>>>>> on first time by patch application.
>>>>>
>>>>> If a commiter want use merge feature, the squash function simulate the
>>>>> application patch.
>>>>>
>>>>> So no opposite to move with this few remark
>>>>>
>>>>> Nicolas
>>>>>
>>>>>
>

Re: git commit workflow for ofbiz

[Jacques Le Roux <ja...@les7arts.com>]

Thanks Taher,

I'm already well used to TortoiseGit and tried before a couple of others but I prefer it (because I also use TortoiseSvn for 14 years). I have also 
Git installed in Eclipse, there are few stuff that I like there.

I also often use Git Bash and when really necessary (never happened so far with Git) turn to my Ubuntu VM.

BTW we will also have to change the buildbot script, but that should be easy, only the repos to change.

@All, any other things in mind we should change?

Jacques

Le 16/01/2019 à 11:00, Taher Alkhateeb a écrit :
> Hi Jacques, I know you are a GUI fan, and for that I recommend this
> tool https://git-cola.github.io
>
> Make sure to install all requirements for a full enjoyable experience
> including viewing the history visually and whatnot
>
> On Wed, Jan 16, 2019 at 12:56 PM Jacques Le Roux
> <ja...@les7arts.com> wrote:
>> Hi,
>>
>> We have some tasks to do (like revert and merge scripts) but I see no problems with that.
>>
>> Apart that I have to think a bit more about the workflow (I guess Taher's proposition should be fine)
>>
>> I must though say that you will certainly see a slow-down on my side. I'm used to a bunch of svn tools I use and will have to find similar for Git. I
>> already use TortoiseGit for 5 years so it should not be a big deal...
>>
>> Jacques
>>
>> Le 15/01/2019 à 07:31, Swapnil Mane a écrit :
>>> +1 for using Git.
>>> Personally, my experience is also very good with Git.
>>>
>>>
>>> - Best Regards,
>>> Swapnil M Mane
>>>
>>> On Mon, Jan 14, 2019 at 2:05 PM Nicolas Malin <ni...@nereide.fr>
>>> wrote:
>>>
>>>> On 12/01/2019 20:56, Taher Alkhateeb wrote:
>>>>> It's awesome to revive this discussion Michael. +1 of course.
>>>>>
>>>>> We need to think practically of our workflows though and whether we
>>>>> want a linear vs non-linear history model. I prefer the latter to
>>>>> allow proper decentralized workflows but it's up to everyone here to
>>>>> decide. I think the overall process is described thoroughly and we can
>>>>> adhere to it for the most part.
>>>> We can easily switch from svn to git without change own commit process
>>>> on first time by patch application.
>>>>
>>>> If a commiter want use merge feature, the squash function simulate the
>>>> application patch.
>>>>
>>>> So no opposite to move with this few remark
>>>>
>>>> Nicolas
>>>>
>>>>

Re: git commit workflow for ofbiz

[Taher Alkhateeb <sl...@gmail.com>]

Hi Jacques, I know you are a GUI fan, and for that I recommend this
tool https://git-cola.github.io

Make sure to install all requirements for a full enjoyable experience
including viewing the history visually and whatnot

On Wed, Jan 16, 2019 at 12:56 PM Jacques Le Roux
<ja...@les7arts.com> wrote:
>
> Hi,
>
> We have some tasks to do (like revert and merge scripts) but I see no problems with that.
>
> Apart that I have to think a bit more about the workflow (I guess Taher's proposition should be fine)
>
> I must though say that you will certainly see a slow-down on my side. I'm used to a bunch of svn tools I use and will have to find similar for Git. I
> already use TortoiseGit for 5 years so it should not be a big deal...
>
> Jacques
>
> Le 15/01/2019 à 07:31, Swapnil Mane a écrit :
> > +1 for using Git.
> > Personally, my experience is also very good with Git.
> >
> >
> > - Best Regards,
> > Swapnil M Mane
> >
> > On Mon, Jan 14, 2019 at 2:05 PM Nicolas Malin <ni...@nereide.fr>
> > wrote:
> >
> >> On 12/01/2019 20:56, Taher Alkhateeb wrote:
> >>> It's awesome to revive this discussion Michael. +1 of course.
> >>>
> >>> We need to think practically of our workflows though and whether we
> >>> want a linear vs non-linear history model. I prefer the latter to
> >>> allow proper decentralized workflows but it's up to everyone here to
> >>> decide. I think the overall process is described thoroughly and we can
> >>> adhere to it for the most part.
> >> We can easily switch from svn to git without change own commit process
> >> on first time by patch application.
> >>
> >> If a commiter want use merge feature, the squash function simulate the
> >> application patch.
> >>
> >> So no opposite to move with this few remark
> >>
> >> Nicolas
> >>
> >>

Re: git commit workflow for ofbiz

[Jacques Le Roux <ja...@les7arts.com>]

Hi,

We have some tasks to do (like revert and merge scripts) but I see no problems with that.

Apart that I have to think a bit more about the workflow (I guess Taher's proposition should be fine)

I must though say that you will certainly see a slow-down on my side. I'm used to a bunch of svn tools I use and will have to find similar for Git. I 
already use TortoiseGit for 5 years so it should not be a big deal...

Jacques

Le 15/01/2019 à 07:31, Swapnil Mane a écrit :
> +1 for using Git.
> Personally, my experience is also very good with Git.
>
>
> - Best Regards,
> Swapnil M Mane
>
> On Mon, Jan 14, 2019 at 2:05 PM Nicolas Malin <ni...@nereide.fr>
> wrote:
>
>> On 12/01/2019 20:56, Taher Alkhateeb wrote:
>>> It's awesome to revive this discussion Michael. +1 of course.
>>>
>>> We need to think practically of our workflows though and whether we
>>> want a linear vs non-linear history model. I prefer the latter to
>>> allow proper decentralized workflows but it's up to everyone here to
>>> decide. I think the overall process is described thoroughly and we can
>>> adhere to it for the most part.
>> We can easily switch from svn to git without change own commit process
>> on first time by patch application.
>>
>> If a commiter want use merge feature, the squash function simulate the
>> application patch.
>>
>> So no opposite to move with this few remark
>>
>> Nicolas
>>
>>

Re: git commit workflow for ofbiz

[Swapnil Mane <sw...@hotwaxsystems.com>]

+1 for using Git.
Personally, my experience is also very good with Git.


- Best Regards,
Swapnil M Mane

On Mon, Jan 14, 2019 at 2:05 PM Nicolas Malin <ni...@nereide.fr>
wrote:

> On 12/01/2019 20:56, Taher Alkhateeb wrote:
> > It's awesome to revive this discussion Michael. +1 of course.
> >
> > We need to think practically of our workflows though and whether we
> > want a linear vs non-linear history model. I prefer the latter to
> > allow proper decentralized workflows but it's up to everyone here to
> > decide. I think the overall process is described thoroughly and we can
> > adhere to it for the most part.
>
> We can easily switch from svn to git without change own commit process
> on first time by patch application.
>
> If a commiter want use merge feature, the squash function simulate the
> application patch.
>
> So no opposite to move with this few remark
>
> Nicolas
>
>

Re: git commit workflow for ofbiz

[Nicolas Malin <ni...@nereide.fr>]

On 12/01/2019 20:56, Taher Alkhateeb wrote:
> It's awesome to revive this discussion Michael. +1 of course.
>
> We need to think practically of our workflows though and whether we
> want a linear vs non-linear history model. I prefer the latter to
> allow proper decentralized workflows but it's up to everyone here to
> decide. I think the overall process is described thoroughly and we can
> adhere to it for the most part.

We can easily switch from svn to git without change own commit process 
on first time by patch application.

If a commiter want use merge feature, the squash function simulate the 
application patch.

So no opposite to move with this few remark

Nicolas

Re: git commit workflow for ofbiz

[Taher Alkhateeb <sl...@gmail.com>]

It's awesome to revive this discussion Michael. +1 of course.

We need to think practically of our workflows though and whether we
want a linear vs non-linear history model. I prefer the latter to
allow proper decentralized workflows but it's up to everyone here to
decide. I think the overall process is described thoroughly and we can
adhere to it for the most part.

On Sat, Jan 12, 2019 at 9:35 PM Deepak Dixit <de...@hotwax.co> wrote:
>
> We are using git since long and it's a great tool for collaboration.
> It has distributed version control system so you don't need an internet
> connection to view history and branch switching.
>
> Thanks Taher for nicly describing it.
>
> +1 for Git.
>
> Thanks & Regards
> --
> Deepak Dixit
>
>
>
> On Sat, Jan 12, 2019 at 11:54 PM Aditya Sharma <
> aditya.sharma@hotwaxsystems.com> wrote:
>
> > +1 for Git
> >
> > Thanks and Regards,
> > Aditya Sharma
> >
> > On Sat, Jan 12, 2019, 9:06 PM Suraj Khurana <suraj.khurana@hotwax.co
> > wrote:
> >
> > > +1 to move from SVN to Git.
> > >
> > > --
> > > Best Regards,
> > > Suraj Khurana
> > > Technical Consultant
> > >
> > > On Sat, Jan 12, 2019 at 7:12 PM Mathieu Lirzin <
> > mathieu.lirzin@nereide.fr>
> > > wrote:
> > >
> > > > Hello Michael,
> > > >
> > > > Michael Brohl <mi...@ecomify.de> writes:
> > > >
> > > > > I'd like to revive this discussion again.
> > > >
> > > > Do we still need to discuss it?  If the response is not obviously “yes
> > > > we should move to Git” now that Git has become ubiquitous and that SVN
> > > > is a moribund tool, then this community has a serious problem.  :-)
> > > >
> > > > Joke aside I think the question should rather be:
> > > >
> > > >    Is there anyone here opposing to the move from SVN to Git?
> > > >
> > > > Thanks for reviving this topic!
> > > >
> > > > --
> > > > Mathieu Lirzin
> > > > GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37
> > > >
> > >
> >

Re: git commit workflow for ofbiz

[Deepak Dixit <de...@hotwax.co>]

We are using git since long and it's a great tool for collaboration.
It has distributed version control system so you don't need an internet
connection to view history and branch switching.

Thanks Taher for nicly describing it.

+1 for Git.

Thanks & Regards
--
Deepak Dixit



On Sat, Jan 12, 2019 at 11:54 PM Aditya Sharma <
aditya.sharma@hotwaxsystems.com> wrote:

> +1 for Git
>
> Thanks and Regards,
> Aditya Sharma
>
> On Sat, Jan 12, 2019, 9:06 PM Suraj Khurana <suraj.khurana@hotwax.co
> wrote:
>
> > +1 to move from SVN to Git.
> >
> > --
> > Best Regards,
> > Suraj Khurana
> > Technical Consultant
> >
> > On Sat, Jan 12, 2019 at 7:12 PM Mathieu Lirzin <
> mathieu.lirzin@nereide.fr>
> > wrote:
> >
> > > Hello Michael,
> > >
> > > Michael Brohl <mi...@ecomify.de> writes:
> > >
> > > > I'd like to revive this discussion again.
> > >
> > > Do we still need to discuss it?  If the response is not obviously “yes
> > > we should move to Git” now that Git has become ubiquitous and that SVN
> > > is a moribund tool, then this community has a serious problem.  :-)
> > >
> > > Joke aside I think the question should rather be:
> > >
> > >    Is there anyone here opposing to the move from SVN to Git?
> > >
> > > Thanks for reviving this topic!
> > >
> > > --
> > > Mathieu Lirzin
> > > GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37
> > >
> >
>

Re: git commit workflow for ofbiz

[Aditya Sharma <ad...@hotwaxsystems.com>]

+1 for Git

Thanks and Regards,
Aditya Sharma

On Sat, Jan 12, 2019, 9:06 PM Suraj Khurana <suraj.khurana@hotwax.co wrote:

> +1 to move from SVN to Git.
>
> --
> Best Regards,
> Suraj Khurana
> Technical Consultant
>
> On Sat, Jan 12, 2019 at 7:12 PM Mathieu Lirzin <ma...@nereide.fr>
> wrote:
>
> > Hello Michael,
> >
> > Michael Brohl <mi...@ecomify.de> writes:
> >
> > > I'd like to revive this discussion again.
> >
> > Do we still need to discuss it?  If the response is not obviously “yes
> > we should move to Git” now that Git has become ubiquitous and that SVN
> > is a moribund tool, then this community has a serious problem.  :-)
> >
> > Joke aside I think the question should rather be:
> >
> >    Is there anyone here opposing to the move from SVN to Git?
> >
> > Thanks for reviving this topic!
> >
> > --
> > Mathieu Lirzin
> > GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37
> >
>

Re: git commit workflow for ofbiz

[Suraj Khurana <su...@hotwax.co>]

+1 to move from SVN to Git.

--
Best Regards,
Suraj Khurana
Technical Consultant

On Sat, Jan 12, 2019 at 7:12 PM Mathieu Lirzin <ma...@nereide.fr>
wrote:

> Hello Michael,
>
> Michael Brohl <mi...@ecomify.de> writes:
>
> > I'd like to revive this discussion again.
>
> Do we still need to discuss it?  If the response is not obviously “yes
> we should move to Git” now that Git has become ubiquitous and that SVN
> is a moribund tool, then this community has a serious problem.  :-)
>
> Joke aside I think the question should rather be:
>
>    Is there anyone here opposing to the move from SVN to Git?
>
> Thanks for reviving this topic!
>
> --
> Mathieu Lirzin
> GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37
>

Re: git commit workflow for ofbiz

[Mathieu Lirzin <ma...@nereide.fr>]

Hello Michael,

Michael Brohl <mi...@ecomify.de> writes:

> I'd like to revive this discussion again.

Do we still need to discuss it?  If the response is not obviously “yes
we should move to Git” now that Git has become ubiquitous and that SVN
is a moribund tool, then this community has a serious problem.  :-)

Joke aside I think the question should rather be:

   Is there anyone here opposing to the move from SVN to Git?

Thanks for reviving this topic!

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

Re: git commit workflow for ofbiz

[Julian Smith <ju...@blockfreight.com>]

Use Git !!! 😃😃😃



On Sat, 12 Jan 2019 at 11:01 pm, Michael Brohl <mi...@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" <sl...@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" <ja...@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
> >>>>
> >>>
> >
> >
>
>

Re: git commit workflow for ofbiz

[Michael Brohl <mi...@ecomify.de>]

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" <sl...@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" <ja...@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
>>>>
>>>
>
>

Re: git commit workflow for ofbiz

[Taher Alkhateeb <sl...@gmail.com>]

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" <sl...@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" <ja...@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 
>>> 
>> 
>> 
> 

Re: git commit workflow for ofbiz

[Taher Alkhateeb <sl...@gmail.com>]

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" <ja...@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 
>>> 
>> 
>> 
> 

Re: git commit workflow for ofbiz

[Jacques Le Roux <ja...@les7arts.com>]

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
>>>
>>
>>
>