[Gambas-user] Switching to GitLab

[PICCORO McKAY Lenz]

Jusssi please do:

http://gambaswiki.org/wiki/howto/git#t14

git whatchanged



Lenz McKAY Gerardo (PICCORO)
http://qgqlochekone.blogspot.com

2017-08-20 14:31 GMT-04:00 Jussi Lahtinen <jussi.lahtinen at ...626...>:

> How do you get the change log with git? "git log" shows only one change
> (most recent?).
> Is this because I cloned the sources with "git clone --depth=1
> https://gitlab.com/gambas/gambas.git"?
>
> Even when I want only the latest dev version, I would still like to know
> what has changed. It's quite important if you do bug hunting.
>
>
> Jussi
>
> On Fri, Aug 18, 2017 at 4:31 PM, Adrien Prokopowicz <
> adrien.prokopowicz at ...626...> wrote:
>
> > Le Wed, 16 Aug 2017 23:14:54 +0200, Benoît Minisini <
> > gambas at ...1...> a écrit:
> >
> > Le 16/08/2017 à 21:30, Adrien Prokopowicz a écrit :
> >>
> >>> Le Wed, 16 Aug 2017 18:30:03 +0200, Benoît Minisini via Gambas-user <
> >>> gambas-user at lists.sourceforge.net> a écrit:
> >>>
> >>>>
> >>>> It's because the download tool of GitLab downloads everything
> >>>> (especially the 'MakeWebSite' project that has a lot big files in it),
> >>>> whereas the "make dist-bzip2" command only package what is relevant to
> >>>> compile and install Gambas.
> >>>>
> >>>> If no 'git' solution exist, maybe I will have to make these source
> >>>> packages manually again, and store them on Sourceforge as usual...
> >>>>
> >>>>  While there are no "git" solutions for this, maybe we should put the
> >>> website in
> >>> its own repository, apart from the rest of the source tree ?
> >>> Same goes for the wiki, the bugtracker, etc.
> >>>
> >>>
> >> Maybe. But the MakeWebSite project is not the only tool located in the
> >> source tree. Or it may not be. It's just the one that takes a lot of
> place.
> >> I will think about that.
> >>
> >
> > Making separate repositories for each project is not a problem : we can
> > have as
> > many repositories as we want in the Gambas group. :-)
> >
> > Also, if the website is in its own repository, it can be hosted with the
> > GitLab Pages service (which I've never tried, but it seems similar to the
> > hosting
> > provided by SourceForge).
> >
> > (I can move it into a new repository without losing the history, if you
> >>> want)
> >>>  As a side-note, we can also use GitLab's Pipelines feature to run the
> >>> make
> >>> dist-bzip2 command and store the results every time we tag a new
> release
> >>> (we can also use it to distribute compiled binaries if we want).
> >>>
> >>>
> >> Ha! This is more interesting. But "make dist-bzip2" is not enough. You
> >> must run it after a full configuration of the source, so it must be run
> on
> >> a clean system, and it needs to be hacked so that it can handle symbolic
> >> links.
> >>
> >>
> > (I'm not sure what you mean by "it needs to be hacked so that it can
> handle
> > symbolic links". Doesn't every system handle symbolic links
> out-of-the-box
> > ?)
> >
> > I forked the repository to make tests on my account, and I configured a
> > small pipeline thats configures the sources and then generates the
> archive.
> >
> > You can see the job result here :
> >
> > https://gitlab.com/prokopyl/gambas/-/jobs/29620075
> >
> > (Warning : Big ./configure log, expect your tab to freeze for a bit !)
> >
> > On the right panel you can browse the Job artifacts, and see it generated
> > the
> > .tar.bz2 archive as an artifact you can download.
> >
> > Unlike the repository source archive, Job artifacts are not meant to be
> > directly
> > downloaded by the users, as anyone in the group can delete them wile
> > cleaning up
> > (they do not expire by default, but we have a 10GB job artifact limit if
> I
> > remember
> > correctly).
> >
> > However, you can configure the pipeline to automatically upload the
> source
> > package
> > to any server you'd like (using SSH, FTP, or anything that has a CLI
> > really).
> >
> > Something I would also like to setup later, is a Pipeline that checks the
> > configuration/build on several Linux distributions on every commit. Since
> > the
> > Pipelines can rely on Docker, we can basically check for most major
> x86_64
> > distributions (and I think we can use qemu for other architectures, like
> > x86
> > or ARM).
> >
> > But that's just an idea, for now. :-)
> >
> >
> > --
> > 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-user mailing list
> > Gambas-user at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/gambas-user
> >
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Gambas-user mailing list
> Gambas-user at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gambas-user
>