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