[Gambas-devel] GitLab - some observations and questions

[Adrien Prokopowicz]

Le Sun, 13 Aug 2017 10:14:48 +0200, adamnt42 at ...176...  
<adamnt42 at ...176...> a écrit:

> I have had a reasonably good play with the GitLab repository over the  
> last couple of days. So here's a few comments and questions.
>
> 1) I am pretty impressed with the Git/GitLab approach. I had an  
> "experience" with Git a couple of years ago and hated it.  The GitLab  
> site makes it so much easier. So +++
> 2) An item of concern (to me) is the appears to be no road map for  
> moving Gambas to Git.  As I said elsewhere, we are about to go into our  
> busiest time of year and the thought of having to move my development  
> system and our 6 sponsor clients to git in an unknown timeline scares  
> me.  As Adrien said somewhere in this list, there is still a lot to be  
> done, it's not just a matter of moving the source. Documentation!!! How  
> can I help? I can write wiki stuff in the evenings to wind down.

Indeed, we need a proper "How To Git" page on the wiki, that explains the  
following :
- How to get the source from the repo (git clone, this one is easy)
- How to contribute (for external developers) : forking the repo, the  
commit log
   format, staying up-to-date, creating merge requests, etc.

> When will the sourceforge repo disappear?

As Benoît said, the sourceforge repo is just read-only, and I don't think  
it will
be ever deleted (unless SourceForge goes down, of course).

> Is there a disaster recovery plan (should, say, the GitLab repo get  
> corrupted)?

I don't think there ever was a proper disaster recovery plan with  
SourceForge either,
but the nature of Git makes it so everyone having a copy of the repo also  
have the
full history of the branch(es) they're on, so we can push it elsewhere if  
needed.

(Actually, it's possible to make a clone without the full history using the
  --depth=1 argument when cloning, but the default is to get the full  
history).

> 3) I use modified versions of the IDE, several components and some of  
> the mainline gambas code.  The reasons for this are arcane, for example  
> my gb.db.postgres is modified to take advantage of postgresql features  
> not supported in other rdbms' and the mods are therefore philosophically  
> at odds with the gambas gb.db common interface approach, so they won't  
> be committed. Since we (here) design in and use postgres ONLY(!  
> corporate rule :-) this is fine for us.   To enable this, I have a local  
> SVN repository cloned off the Sourceforge one and can adequately manage  
> our differences with the eSVN tool.  So,
> 3a) Can I run a local repository clone off the GitLab repo?  If so, it  
> looks like an even better approach than what we do now. I could  
> envisage  that we would have a close of "master" on our dev server with  
> a main branch "local" where I can manage our differences.  Then off  
> that, I might have some other branches where I (me) can play with other  
> changes while Felicity and my other developers can use a Gambas from  
> "local"? Have I got the right idea? Is this feasible?

You can definitely do this, on your own server, but GitLab supports it  
too. :)

In GitLab, on the repository's page, you can click the "Fork" button.
It will create a copy of the Gambas repository to your account. You can  
then
clone this repository on your machine and push any commits you want, it  
will
only affect your copy.

In order to stay up-to-date with the main repository, you will have to  
merge
the original master branch into your own. To do this, you can add a second
(read-only) remote to your local copy, using this command :

git remote add upstream https://gitlab.com/gambas/gambas.git

I called the remote "upstream" here, but you can call it as you want.
(You can also use SSH, I just put the HTTPS here because credentials are  
not
required to use it).

Then, when you are on your master branch, you can ask git to merge the  
master
branch from the original repository this way :

git pull upstream master

It then works like a regular merge, you only have to do this from time to  
time
whenever you want to update your Gambas version.

If you do not want to do this using GitLab but on one of your own servers  
instead,
you will first have to set up a bare (i.e. empty) Git repository on your  
server :

https://git-scm.com/book/it/v2/Git-on-the-Server-Setting-Up-the-Server

When it is done, use the local copy of the Gambas repo you (may have)  
already
cloned, and add an origin that points to your server, using regular SSH :

git remote add bruceserver  
git at ...770...:wherever/is/your/repo/gambas.git

Then you can clone it, and add the original repo as a remote just like  
above with
GitLab.

This actually is common practice in OSS projects (except for the  
self-hosted version),
so this will certainly end up in the contributing guide on the wiki.

> 3b) Here's another example. I have a modified version of the FProperty  
> class from the IDE that supports something I suggested a few years ago -  
> "custom" property editors.  There are two reasons why it was not  
> committed to the Sourceforge repo. a) Benoît did not like the idea at  
> the time and b) I had to redesign most of the class code, mainly because  
> I couldn't understand how the original works, which has resulted in a  
> FProperty class that is completely different to the official one.   
> SVN/eSVN handles this fairly easily as the file is marked "Replaced" and  
> no merging or anything is required (until someone changes the official  
> version for some reason! Given that the last change was rev 7730, I live  
> in hope.)  Can Git handle that situation?

 From my experience, Git handles very well 90% of the merges. For completely
different files however, it will stop halfway through the merge, and mark
some files as "conflicting". You can then use the `git mergetool` command,
which will walk you through each conflicting file using your favorite diff  
program
(I personally use KDiff3, but it supports many more).
When done, you just commit your changes, and it's merged and ready to push.

> 3c) One shortcoming appears to me to be the way commits are identified.  
> I mean it obviously works and that but I miss the SVN rev number which  
> was sequential and relevant across all branches and most importantly was  
> "human digestible".  Looking at the recent GitLab commits, the revision  
> id's appear to be things like "dcabf06c" ( Fabian's [GB.TERM.FORM] *  
> NEW: New TermListBox widget.) Is there some logic to these random  
> looking id's?

What you have here is the "short" commit ID (which is enough 99% of the  
time).
The full ID is actually this : dcabf06cbf725137810408ed7c10c167b6863956.

The logic behind those ids is basically "please don't collide". Because  
Git is
decentralized in nature (see the above examples of across-origins merges  
and commits),
you cannot have both a sequential and unique revision number.

This is even the case on a single repository : if users A and B both  
commit to their
local repositories, since Git doesn't know about each other's changes  
(until they get
pushed and pulled), it cannot just do rev+1 like SVN does (you can think  
of Git as
peer-to-peer, while SVN is just client/server).

However, you can use `git rev-list --count HEAD` to count the number of  
commits since
the beginning. This number is not reliable for representing a specific  
commit, but it
can vaguely tell you how behind you are from recent changes.
GitLab also creates a small visual representation of "x commits behind / x  
commits
ahead" on its branch list page  
(https://gitlab.com/gambas/gambas/branches), which can
be useful too.

> 4) Commit comments!!! The SVN style was so easy to follow! Keep the  
> standard! Can it be enforced in Git?

The commit comment style is actually a format enforced by Benoît, it has  
nothing to
do with SVN.
I actually like it a lot, and I have already used it in a number of other  
Git projects.
I only apply a small change to it : I use the first line as a short  
description of what
the commit is, before adding the full changelog.

This is because all Git tools show the first line as a short commit  
description
(like here : https://gitlab.com/gambas/gambas/commits/master), and just  
having the first
section tag is unhelpful at best.
Since Benoît's standard ignores non-prefixed lines, it doesn't matter and  
is skipped when
making the final revision changelog. :)

> Ah wait! One more!
> 5) Git clients.  I have tried the following:
> * gitk - not bad
> * qgit - better
> * giggle - feature rich and functionally poor, but the best change  
> browser of the three
> (and several CLI front ends).
> Any other suggestions (for managing my local clone) ?

This is my personal opinion, but I have not found a single standalone git  
client
on linux that I like (especially for viewing changes before committing).  
Oddly enough,
I like the Git tools integrated in IDEs much better. I've used QtCreator,  
NetBeans,
The JetBrains IDEs and probably others I forgot.

So for now I use mostly the command line, but in KDE I also use the small  
Git
integration plugin for Dolphin, and with a small ZSH integration that shows
the Git current branch & working copy status in my prompt.

I am currently prototyping a Gambas component that interfaces with  
libgit2, so we
can have a proper integration within the IDE, and why not make a Gambas git
graphical client in the future. :-)

-- 
Adrien Prokopowicz