[Gambas-devel] GitLab - some observations and questions

[adamnt42 at ...176...]

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. When will the sourceforge repo disappear? Is there a disaster recovery plan (should, say, the GitLab repo get corrupted)? 
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?  
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? 
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?
4) Commit comments!!! The SVN style was so easy to follow! Keep the standard! Can it be enforced in Git?

That's enough for now, more later. (I'm busy trying to translate a certain wiki page.)

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

regards
bruce

-- 
B Bruen <adamnt42 at ...769... (sort of)>