[openlp-dev] Exploring GitLab

[googol]

Hello,

some supporting words from me. At (my) university they teach "git". And
if they don't teach git, they teach svn - not bzr. I think it is crucial
to make it as easy as possible to contribute to OpenLP. When I ask my
fellow students what CVS they use by 99 % all of them will say 'git'.
In addition, the fork/pull request is widely known and you normally
don't have to think about "how to contribute" to a project, you just go
for it. OpenLP currently has an own dedicated wiki page for that.

-> so I think when we use git this will be good for contributions

The development process for OpenLP is much easier as it will be for most
companies. So we should not compare those development processes. Also
git evolved - as migration is always difficult the migration tools
need(ed) time to mature. And we all know that 10 years are a lot in IT
"time reckoning". 10 years ago, git was 3 years old. Also 10 years ago,
the first android version was released. By the way, when talking about
dates: bzr development is somewhat "slow". The last commit in trunk was
in *March 2017*. [1]

-> I think to implement the same development process we have with bzr
should not be any problem

Certainly: git is different. But it is - as often - just a matter of
learning new things and getting used to them. [2] To get "up and
running" with git is not that much different than with bzr. Nobody
requires that people rewrite their history/commit or use cherry-picking.
Also nobody has to use interactive stashing or adding. But git still
leaves room for advanced usage (such as interactive adding or
cherry-picking).

-> we should stay with plain git without the fancy stuff [at first ;-)]

Sure, if OpenLP stays with svn this is alright but I think the migration
is an opportunity. And I am existed that we will try it out.

Cheers :-)

[1] https://code.launchpad.net/bzr
[2] I personally found it easier to understand what git is doing.

Am 21.08.2018 um 17:39 schrieb Raoul Snyman via openlp-dev:
>> I fully recognize that I'm new to bzr and openlp, so my opinion probably
>> counts for less than two cents, but so far I haven't seen any bzr feature
>> that would make me want to switch all my projects away from git. :)
> 
> My guess is that you've only ever used git, right? :)
> 
> When OpenLP started, we were using CVS and SourceForge. When SourceForge
> rolled out Subversion, I moved OpenLP to Subversion. When distributed
> version control systems started, I looked into the different options.
> git had (and still has) completely different actions for certain
> commands ("cvs revert", "svn revert", "bzr revert" and "hg revert" all
> do the same thing, "git revert" does something different), and a friend
> of mine was advocating for Bazaar (they used it at their company). Also,
> GitHub and GitLab (and Gitorius) didn't exist but Launchpad did.
> 
> So this friend of mine helped me migrate OpenLP to Bazaar and Launchpad.
> It was difficult (just like the cvs -> svn migration), but once we were
> onto Bazaar the commands worked the same as Subversion, and most of the
> concepts were the same. Bazaar was essentially a distributed take on
> Subversion (and let's be honest, Subversion merging was not as bad as
> people make it out to be), and was easy to adapt to.
> 
> A couple of years later, the company I was working for decided to move
> from Subversion to git, and we all got badly burnt by git because it is
> so different to other version control systems. I helped migrate all our
> repositories, and the migration was even worse than svn to bzr. I also
> had to run around to all the QA folk and all the designers every day
> helping them fix the problems they created for themselves by using git.
> At the time, GitHub still didn't exist.
> 
> It was horrendous, and I was git'ed out after that.
> 
> So, from my point of view, "so far I haven't seen any git feature that
> would make me want to switch all my projects away from bzr" -- and I use
> git on a daily basis with my job.
> 
> I leave you with some enlightenment ;-)
> http://stevelosh.com/blog/2013/04/git-koans/
>