[Gambas-devel] GitLab - some observations and questions

[adamnt42 at ...176...]

Thanks for that info Adrien, you have cleared up a lot of what I thought but could not confirm to my own satisfaction from reading/playing.
To save you having to wade through the below here are a few comments (referenced to my original points).
2) I agree and would like to help with the How To. (I tried to "translate" Piccoro's well intentioned draft page but got lost.) I am currently drafting a set of wiki pages locally (using Olivier Cruille' s most excellent  markdown editor from the farm!) I feel we may need two pages (at least) one for contributors and one for non-contributing users. There is just too much to write for each one for a single page and it might be confusing for the latter to be subjected to the workflows, updates etc etc. Your thoughts?
2) Regarding the r/o status of the sourceforge repository. Ah I see, so I guess I'll just limit us to "emergency patching" for now.
2) DRP. Ok, that makes me a lot more confident!
3) and 3a) (Local clone) Thank you very much for that info - much clearer now!
3b) I am still not sure whether I am happy about the loss of the "replaced" status from SVN. :-( I guess I'll just wait and see). P.S. I generally use diffuse, which I have managed to integrate with most of the GUI client's I've tried so that is some pain killer I suppose.
3c) revision ID's : ah now I get it! I guess I'll get used to it.
4) comments (snip pasted from below)
> 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. :)

Hmmmmmm. My experience is converse.  I like to see what "area" a change affects as a summary and the details I can review in the fullness of time.  For example, a change to [GB.JIT] is not going to worry me too much as we don;t use it. (There are reasons.) But a change to [GB.DB] or [GB.DB.POSTGRES] will affect us so I want to review that asap.  How about a compromise? Put the section tag and a short description on the first line. P.S. I thought that the SVN could enforce the commit comments because some years ago I set up a little "template" in esvn to "enforce" it - I just forgot all about that.  I see some of the clients seem to have a similar feature, I look at them some time.

5) (clients) Yes. they all do seem to be strong in some areas and &#$^&# weak in others. Giggle, for example is great at browsing the change history but lousy at managing commits, etc.  Just thought someone might have found the "magic" answer.

5) (gambas IDE integration) Love to help! With some reservations I know my way around the IDE pretty well. Let me know when your component is usable. (Actually I really should focus on that autotools packaging fix though.)

Thanks again.
bruce


On Sun, 13 Aug 2017 12:38:55 +0200
"Adrien Prokopowicz" <adrien.prokopowicz at ...176...> wrote:

> 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
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Gambas-devel mailing list
> Gambas-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gambas-devel


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