+1 On Fri, Jan 25, 2019, 1:29 PM Deepak Dixit <[email protected] wrote:
> Looks good Michael. > > Thanks & Regards > -- > Deepak Dixit > > > > On Fri, Jan 25, 2019 at 1:54 PM Michael Brohl <[email protected]> > 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 < > [email protected]> > > > 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" <[email protected]> > > >>> To: [email protected] > > >>> 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" <[email protected]> > > >>> To: [email protected] > > >>> 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 > > >>> > > >> > > > > >
