Recent

Author Topic: FPC & Lazarus moving to gitlab  (Read 100167 times)

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11383
  • FPC developer.
Re: FPC & Lazarus moving to gitlab
« Reply #30 on: June 24, 2021, 02:05:07 pm »
"master"

master is deprecated nowadays, the new suggested name is "main".

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9792
  • Debugger - SynEdit - and more
    • wiki
Re: FPC & Lazarus moving to gitlab
« Reply #31 on: June 24, 2021, 02:35:59 pm »
All my scripts (mostly FPC TProcess based) and every other infrastructure is invalidated. Worse, git seems to want bash for nearly everything which makes scripting a pain on Windows, specially when multiple driveletters are involved.
What "shell" are you currently using?

git is callead as a command/exe.
I have used it from
cmd  => so very seldom, because I dislike cmd.
the shell that came with git-for-windows
mingw/msys

Quote
I'm reluctant to do this all again, in case the gitlab thing doesn't work out in a few years, and we go back to hosted.
This is nothing to do with gitlab, but with git.

If we moved svn to be hosted by sourceforge, it still be svn.

Our git repro remains valid, whoever hosts the server part. If gitlab becomes unavailable then other hosters, or self hosting are very possible (but right now the choice is gitlab)

Quote
Quote
(Yes, I can write a wrapper for svn too. But git already includes it)

Yes. But the move invalidates more scripting, than these kind of limited use gadgets actually add. Instead we have to do with some pre-cooked gitlab pages.

Also, getting scripting crossplatform will be harder. I used FPC for that, but with GIT in special bash shells that will be harder.
I don't quite follow, including I am not sure about what is current, and what is future.

Of course existing scripts (or fpc apps) that call svn, must be changed to call git, and they must be adapted to the new syntax, the  new output, and maybe the concept.
That is a once off for git.
As long as we stay on some git, that stays valid.

And where git is to call a script or program (like in bisect) that can be an fpc program. Or a script that first builds the fpc app, and the calls it.

sorry if the last part is off... As I said not sure about interpreting your statement...

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11383
  • FPC developer.
Re: FPC & Lazarus moving to gitlab
« Reply #32 on: June 24, 2021, 03:05:41 pm »
All my scripts (mostly FPC TProcess based) and every other infrastructure is invalidated. Worse, git seems to want bash for nearly everything which makes scripting a pain on Windows, specially when multiple driveletters are involved.
What "shell" are you currently using?

I use the default shell on most targets. On *nix this is usually some sh derivate, on Windows
the default shell, cmd.exe.   As said, my experiences with bash shells on Windows is bad (even though I'm a 26 years long sh/Bash user). You can't copy paths from the explorer any more (due to \ vs /), driveletters require special handing, quoting rules etc are different etc.

Worse, the whole msys movement has actually regressed the situation, in that there were more mingw binaries working with proper windows conventions ten years ago, than now.

Quote
git is callead as a command/exe.
I have used it from
cmd  => so very seldom, because I dislike cmd.
the shell that came with git-for-windows

And does git properly understand driveletters ?

Quote
This is nothing to do with gitlab, but with git.

If we moved svn to be hosted by sourceforge, it still be svn.

True. The example was bad. It was just a remark about not wanting to invest heavily again, since this might also be temporary again. For windows users doubly so, since the degree to which git+associated tools are ported to Windows might vary over time.

Quote
[Of course existing scripts (or fpc apps) that call svn, must be changed to call git, and they must be adapted to the new syntax, the  new output, and maybe the concept.

Yes. Every done investment is void.   The more complex ones are in the FPC release and fixes branch maintenance realm though, which will now be done by Florian. So I won't have to redo them.

Quote
That is a once off for git.

It was a one of for subversion too at one point :-)

Quote
re git is to call a script or program (like in bisect) that can be an fpc program. Or a script that first builds the fpc app, and the calls it.

If git passes things like drivelettes and paths consistently yes. Otherwise you have to hack around that again, to interpret /drive/c etc.

I've had some extremely bad experiences with this in the FPC early years with cygwin gdb.

The only sane solution is to minimize the use and so usually that means that things like compelex scripting are out

But at least in the GDB case there was no choice. Now we are leaving a perfectly windows integrated tool for one that is not.
« Last Edit: June 24, 2021, 03:09:47 pm by marcov »

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9792
  • Debugger - SynEdit - and more
    • wiki
Re: FPC & Lazarus moving to gitlab
« Reply #33 on: June 24, 2021, 03:55:13 pm »
As said, my experiences with bash shells on Windows is bad (even though I'm a 26 years long sh/Bash user). You can't copy paths from the explorer any more (due to \ vs /), driveletters require special handing, quoting rules etc are different etc.
Quote
And does git properly understand driveletters ?

Well, if run from cmd then yes, as far as I tested.
If run from a unix like sh/bash/... then no.

First of all, git expects to be run inside the repro dir (can be in a subdir, but not outside). At least afaik.
So most of the time you switch into that dir first.

But the following 2 examples worked fine, run within cmd.

The first part points to an existing repro on my b hard-drive.
The 2nd specifies a target, which is a new folder beneath the current dir (current dir was on c drive)
Code: Bash  [Select][+][-]
  1.     git clone b:\GITLAB_TEMP_WORK\t2_gitlab_conv_laz  temp

And when I am inside the git dir, and want the log for a specific file (again, run from cmd)
with backshlash
Code: Bash  [Select][+][-]
  1.     git log -n3 --oneline ide\main.pp

So it seems to work, but I have no in depth testing/experience with it. cmd is not to my personal likings.

Quote
True. The example was bad. It was just a remark about not wanting to invest heavily again, since this might also be temporary again. For windows users doubly so, since the degree to which git+associated tools are ported to Windows might vary over time.
s/git/svn/  => and the statement is either as likely as, or even more worrying.

I think the fact that any software might cease to exist (entirely or partly) is not an argument (unless there are actual signs that it is about to happen.)

Here we could same as good say, Windows users may have a problem, because Windows may cease to exist (it already has a subsystem for linux, it may just drop the system around it, and be linux in itself...)  ;)

Sorry, but I think your statement called for a slightly overdone answer....

Quote
Yes. Every done investment is void.   The more complex ones are in the FPC release and fixes branch maintenance realm though, which will now be done by Florian. So I won't have to redo them.

Yes, that is the nature of change. It usually requires investment. And if it is done correctly, in the end the benefits will be more than the cost.

However, the distribution of benefits and cost is not always fair. Some loose out, some win. The aim is that the amount of winners is massively higher.

Leaving todays knowledge about the environment aside, would you rollback the invention and spread of the automobile? Because lots of the people who cared about horses (for horse drawn carriages) lost their job?


Quote
Quote
...Of course existing scripts (or fpc apps) that call svn, must be changed ...
That is a once off for git.
It was a one of for subversion too at one point :-)
So you agree?
I guess you talk about the CVS to SVN?
So did the change for fpc turn out to be good? Or would it be better, if fpc was still using cvs?

Quote
If git passes things like drivelettes and paths consistently yes. Otherwise you have to hack around that again, to interpret /drive/c etc.

I've had some extremely bad experiences with this in the FPC early years with cygwin gdb.

The only sane solution is to minimize the use and so usually that means that things like compelex scripting are out

But at least in the GDB case there was no choice. Now we are leaving a perfectly windows integrated tool for one that is not.
See initial part of my answer.
« Last Edit: June 24, 2021, 03:58:07 pm by Martin_fr »

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11383
  • FPC developer.
Re: FPC & Lazarus moving to gitlab
« Reply #34 on: June 24, 2021, 04:38:01 pm »
Well, if run from cmd then yes, as far as I tested.
If run from a unix like sh/bash/... then no.

Well that is something.

Quote
First of all, git expects to be run inside the repro dir (can be in a subdir, but not outside). At least afaik.
So most of the time you switch into that dir first.

When I wrote it, I was mainly thinking about export, but also to reduce commands to single lines again, since git seems to often need multiple commands with options for simple operations.

Helper apps to embed the checkout hash into apps also matter.

Though maybe tortoise git will eliminate them.  And maybe I should lighten up on the scripting front since I won't have to recreate the heaviest ones.

Quote
Quote
True. The example was bad. It was just a remark about not wanting to invest heavily again, since this might also be temporary again. For windows users doubly so, since the degree to which git+associated tools are ported to Windows might vary over time.
s/git/svn/  => and the statement is either as likely as, or even more worrying.

No. SVN was well integrated into Windows from the start. It didn't come with bash, and all needed basic commands were single issue without the need for scripting. It also needed minimal configuration. (though still more than CVS, but that was because CVS had awkwardly weak authentication/encryption)

Quote
This is why
I think the fact that any software might cease to exist (entirely or partly) is not an argument (unless there are actual signs that it is about to happen.)

We'll see. I just got horrible vibes from everything GIT. The constant pushing of bash might have been something that triggered me.

Quote
Here we could same as good say, Windows users may have a problem, because Windows may cease to exist (it already has a subsystem for linux, it may just drop the system around it, and be linux in itself...)  ;)

Nobody knows anything what will happen on the real long term. Usually it is also never so black and white, technologies more often change markets and heavily mutate than outright disappear.

But yeah, the year of Linux on the desktop might finally happen, and Linux might break out of its current server and power user audience. But I won't hold my breath after hearing such things about Linux longer than that I use windows.

The naive user sees the name of the product survive and assumes continuity that is not really there in reality. This is the danger of superficial analogies like the car one that you produced..

That something survives doesn't mean users on all paths are safe. Zeppelins still exist, but aren't as dominant as some people would have hoped. And then I'm not even asking Hindenburg passengers for comments ;-)

All joking aside, just survival of a concept doesn't mean that details investments are safe. To stay in your car analogy, early movers in post combustion car are writing off investments in hybrid vehicles because in many markets all electric is moving much faster than expected.

 
Quote
Yes, that is the nature of change. It usually requires investment. And if it is done correctly, in the end the benefits will be more than the cost.

However, the distribution of benefits and cost is not always fair. Some loose out, some win. The aim is that the amount of winners is massively higher.

If a proper cost/benefit analysis was done in the first place. I'm not convinced this is actually the case.

Compiler devels wanted (easier?) forward and local branches, and the server was up for renewal which was tempting for the people maintaining the infrastructure. And that actually forced the issue, not the GIT "features".

All the rest is piled sentiment on to make it palatable.

Quote
Quote
Quote
...Of course existing scripts (or fpc apps) that call svn, must be changed ...
That is a once off for git.
It was a one of for subversion too at one point :-)
So you agree?
I guess you talk about the CVS to SVN?

Yes. But that was different, because subversion had advantages for all user groups, not just a happy few that heavily use forward branches.

Also CVS development actively point to SVN as a successor, it was leaving a phased out (EOL) product. This is not the case with svn->GIT, and the tools are in many case a regression with git.

Quote
So did the change for fpc turn out to be good? Or would it be better, if fpc was still using cvs?

Definitely positive, but it still cost the project over an year, and while a bigger change in feature set, the amount of features used from the VCS was actually less. Little scripting and fixed procedures (e.g. for release and fixes branch maintenance).

So I expect it to be worse in this case, with smaller gains (which are also very unevenly distributed, and for some it might remain a netto minus).

I was initially negative about CVS->SVN too, I considered the change not worth the advantage (which back then for the common user was mostly renaming, though also back then the compiler devels were only interested in branching).

But when the migration got closer and more detailed, I got more positive.  Many small things were better. Also the EOL status became more prominent in the period between initial talks about migration and the actual transition. And Peter (and Jonas too iirc) prepared it very well.

Neither of those cases are now the case. The windows tooling is a step back, the commands are more complicated, the preparation less. And most importantly, SVN was not EOL.
« Last Edit: June 24, 2021, 05:25:12 pm by marcov »

Kays

  • Hero Member
  • *****
  • Posts: 569
  • Whasup!?
    • KaiBurghardt.de
Re: FPC & Lazarus moving to gitlab
« Reply #35 on: June 24, 2021, 04:55:04 pm »
[…] The Free Pascal and Lazarus teams are in the process of switching to Gitlab to manage their source code and issue reports. […]
That’s great news! Kudos to all that are involved in the migration process, writing and testing migration scripts and, let’s not forget, dealing with the non-technical issues.

[…] Statement of fact: I've got too much else on my plate to be prepared to continue with trunk since the change will involve learning a new toolset. Sorry.
That’s fair. I mean, “we”, collectively as the FPC project, are (or should have been) aware that some contributors will stop contributing just because of that, while at the same time we ensure the project’s longevity by finally switching to more “modern” tools like Git.
[…] But to conclude, every change that happens in the world will be positive for some, and less good for others. The hope is that the amount of those benefiting will grossly outweigh the amount of those who don't. […]

"master"
master is deprecated nowadays, the new suggested name is "main".
It ain’t “deprecated”, you know that, right? It’s just that some people like to force their world view, their ideology on others. Case in point “master” supposedly implied owning slaves. It’s rather fascinating that 99% of the English speaking world, i.e. first and second language English speakers mostly living outside of the US, don’t even understand the fuss about “master” yet we still have to put up with that shit, that language imperialism.
Yours Sincerely
Kai Burghardt

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11383
  • FPC developer.
Re: FPC & Lazarus moving to gitlab
« Reply #36 on: June 24, 2021, 05:02:06 pm »
"master"
master is deprecated nowadays, the new suggested name is "main".
It ain’t “deprecated”, you know that, right? It’s just that some people like to force their world view, their ideology on others. Case in point “master” supposedly implied owning slaves. It’s rather fascinating that 99% of the English speaking world, i.e. first and second language English speakers mostly living outside of the US, don’t even understand the fuss about “master” yet we still have to put up with that shit, that language imperialism.

Yeah, that. But since we can now avoid exactly such discussions in the future from both at no real cost (since as new git repos we are not invested in "master"), it is sensible to do so, regardless of what you think about the actual change.

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9792
  • Debugger - SynEdit - and more
    • wiki
Re: FPC & Lazarus moving to gitlab
« Reply #37 on: June 24, 2021, 05:20:37 pm »
but also to reduce commands to single lines again, since git seems to often need multiple commands with options for simple operations.
You can configure git aliases.
Code: Bash  [Select][+][-]
  1. git config alias.slog 'log --oneline'
  2. git slog -n 3

There are also aliases where git calls an external command, usually a shell. Not tested with anything else. Maybe it will do with cmd, but I do not know that.

Quote
Helper apps to embed the checkout hash into apps also matter.
Code: Bash  [Select][+][-]
  1. git describe
However it requires the correct tags to be set.

Quote
No worries, I returned the favour. Don't wrestle with pigs. You get dirty, and the pig likes it :-)
Well, I might like it too. And I love bacon. :) 

Quote

Quote
I guess you talk about the CVS to SVN?
Yes. But that was different, because subversion had advantages for all user groups, not just a happy few that heavily use forward branches.

Also CVS development actively point to SVN as a successor, it was leaving a phased out (EOL) product. This is not the case with svn->GIT, and the tools are in many case a regression with git.

I wasn't there back then, so I can't say much about it. Speculative, maybe some people would have liked to stay on cvs, at least for some more time. They might not have spoken up, so how knows. But well speculation to be ignored....

Not sure about regressions, as I do not know what you refer too. Unless of course the need to adapt all scripts...

Quote

Quote
So did the change for fpc turn out to be good? Or would it be better, if fpc was still using cvs?

Definitely positive, but it still cost the project over an year, and while a bigger change in feature set, the amount of features used from the VCS was actually less. Little scripting and fixed procedures (e.g. for release and fixes branch maintenance).

So I expect it to be worse in this case, with smaller gains (which are also very unevenly distributed, and for some it might remain a netto minus).
Well, that I can not take away. It will take it's time. And for some of us, be a bigger learning curve....

And I can not predict, who benefits, and who not  -> If I could do that, I would have a booming business. :)

I can say, that I already benefited. I have for the past year (or year and a half) run my own 2-way mirror for Lazarus, and used it as if it was git. It has helped me a lot, and certainly saved me some time on my fpdebug work. (I.e. I used local commits as savepoints, and when I needed to recover from a mistake changing lots of sources, that saved me time / also it allowed me to compare before/after easily)
But I must also admit, that I spent a good 2 month of hard learning and falling (though I did not have anyone to ask, I had to google everything => so I hope that given that here we can support each other, learning time will be less)

Though, yeah, that does not help you.

Quote
Neither of those cases are now the case. The windows tooling is a step back, the commands are more complicated, the preparation less. And most importantly, SVN was not EOL.
I am trying to help with getting from svn to git. But yes, time is quite short. And I have other stuff too.

EOL has worked well for me, using git.

On Windows:
Code: Bash  [Select][+][-]
  1. git config core.autocrlf true

And there is .gitattributes, where you can make settings per file extension, folder, some kind of pattern, or individual file.
But I would need to lookup the details.

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9792
  • Debugger - SynEdit - and more
    • wiki
Re: FPC & Lazarus moving to gitlab
« Reply #38 on: June 24, 2021, 05:30:29 pm »
more “modern” tools like Git
This is not helpful.

There were many reasons (I wont go into details) to switch (and there would have been some reasons not to, but well it went as it went).
This is certainly not a hype driven move.

However, if people like it, because it goes along with their favourite hype, they are welcome.


Quote
It’s just that some people like to force their world view, their ideology on others.
It's a lot more complicated than this. But this is not for here to be discussed.
And that is not that I want to suppress the discussion. Heck, personally I'd open a special sub-board for this... But we have a topic, and it is Pascal. (or in this thread svn/git)

So please note, that I will moderate the discussion, simply so we can focus on the actual topic.

PM, me if any of this needs clarification. Thanks.

As for the branch naming, I suggest the individual teams can discuss that on their private mail lists.
« Last Edit: June 24, 2021, 05:34:08 pm by Martin_fr »

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11383
  • FPC developer.
Re: FPC & Lazarus moving to gitlab
« Reply #39 on: June 24, 2021, 05:47:30 pm »
but also to reduce commands to single lines again, since git seems to often need multiple commands with options for simple operations.
You can configure git aliases.
Code: Bash  [Select][+][-]
  1. git config alias.slog 'log --oneline'
  2. git slog -n 3

I know, but that is a dirty hack/workaround at best, doesn't fix the problem (requires configuration, complex in tutorials etc).

Quote
Quote
Yes. But that was different, because subversion had advantages for all user groups, not just a happy few that heavily use forward branches.

Also CVS development actively point to SVN as a successor, it was leaving a phased out (EOL) product. This is not the case with svn->GIT, and the tools are in many case a regression with git.
I wasn't there back then, so I can't say much about it. Speculative, maybe some people would have liked to stay on cvs, at least for some more time. They might not have spoken up, so how knows. But well speculation to be ignored....

Yes, there were. Roughly the same group of more occasional users.  One could argue then it was the EOL status of CVS, now it is the infrastructure decision.

Quote
Not sure about regressions, as I do not know what you refer too. Unless of course the need to adapt all scripts...

Regression in user experience (tortoisegit compared to tortoisesvn), single vs multi command etc.

Quote
Well, that I can not take away. It will take it's time. And for some of us, be a bigger learning curve....

A gigantic one, since now work and other projects aren't changing with it. IOW it must all be done in FPC time.

Quote
I can say, that I already benefited. I have for the past year (or year and a half) run my own 2-way mirror for Lazarus, and used it as if it was git. It has helped me a lot, and certainly saved me some time on my fpdebug work. (I.e. I used local commits as savepoints, and when I needed to recover from a mistake changing lots of sources, that saved me time / also it allowed me to compare before/after easily)

That is roughly the same scenario as for the compiler devels, deep into one subject/module.
Contrary to that I work all over the libraries, improving compatibility, small bugs, and doing the release branch work. I also work on multiple machines, which make local branches less useful, unless you create a complete shadow VCS.

Quote
But I must also admit, that I spent a good 2 month of hard learning and falling (though I did not have anyone to ask, I had to google everything => so I hope that given that here we can support each other, learning time will be less)

Though, yeah, that does not help you.

I don't have the time, so I gave up my central tasks. Now I'm just going to be bit player and committer, and we'll see in one or two years if I want to bear responsibility for something central again.

Quote
EOL has worked well for me, using git.

EOL as in CVS being end-of-life.
« Last Edit: June 24, 2021, 05:49:06 pm by marcov »

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9792
  • Debugger - SynEdit - and more
    • wiki
Re: FPC & Lazarus moving to gitlab
« Reply #40 on: June 24, 2021, 06:07:15 pm »
Contrary to that I work all over the libraries, improving compatibility, small bugs, and doing the release branch work. I also work on multiple machines, which make local branches less useful, unless you create a complete shadow VCS.
Well, I don't know your workflow.

But again (and maybe there could be something for you in it) for me git did help, with testing my work on my VirtualMachines, and on my Laptop.

On my main working machine, I have my normal git clone.

I have then a git-server running, making that directory available as a server.
All my VM, and my laptop have that server as remote. (they have both, my local, and the true online remote)

So now I can commit (without pushing) either to the local default branch, or to a feature branch. Then I can pull those changes. If I make change I can push them back => though that needs a (temporary) feature branch.

So I no longer need shared folders, to move files or patches around. Or have my workindir entirely on a shared folder...


Quote
EOL as in CVS being end-of-life.
Ups...

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: FPC & Lazarus moving to gitlab
« Reply #41 on: June 24, 2021, 06:10:54 pm »
I really don't want to prolong the agony but...

I mean, “we”, collectively as the FPC project, are (or should have been) aware that some contributors will stop contributing just because of that, while at the same time we ensure the project’s longevity by finally switching to more “modern” tools like Git.

I think one should be careful how one phrases that sentiment, since many among "the great unwashed" unashamedly judge Pascal by the received wisdom that "it's not modern".

Quote
Case in point “master” supposedly implied owning slaves. It’s rather fascinating that 99% of the English speaking world, i.e. first and second language English speakers mostly living outside of the US, don’t even understand the fuss about “master” yet we still have to put up with that shit, that language imperialism.

I am proud to say that I come from a family of schoolmasters.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

avra

  • Hero Member
  • *****
  • Posts: 2514
    • Additional info
Re: FPC & Lazarus moving to gitlab
« Reply #42 on: June 24, 2021, 06:19:59 pm »
< SARCASM MODE ON > :-[ :-[ :-[
If I remember well, many have complained that much more developers would contribute if GIT was the main version control system. Can't wait for that to happen...
< SARCASM MODE OFF > ;)  ;)  ;)

I wonder what was the motivation for choosing gitlab over github? Self hosting possibility? Non M$? Code open sourced and available? Free storage size? Other?

Some guide will be needed for smoother crossing from Mantis - explaining several best practice use cases with common category/label mapping. Otherwise everyone will have his own idea on how to achieve that...
« Last Edit: June 24, 2021, 06:21:49 pm by avra »
ct2laz - Conversion between Lazarus and CodeTyphon
bithelpers - Bit manipulation for standard types
pasettimino - Siemens S7 PLC lib

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: FPC & Lazarus moving to gitlab
« Reply #43 on: June 24, 2021, 06:28:39 pm »
I have then a git-server running, making that directory available as a server.
All my VM, and my laptop have that server as remote. (they have both, my local, and the true online remote)

Etc. Again, I for one have never denied that Git is at least adequate (most would say better than adequate) as a tool for collaborative development.

My indignation is focussed on being obliged to embrace it in order to continue using Trunk and sporadically raise issues, which I consider to be unreasonable.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11383
  • FPC developer.
Re: FPC & Lazarus moving to gitlab
« Reply #44 on: June 24, 2021, 06:32:55 pm »
Well, I don't know your workflow.

Well, neither do I atm ;), since fixes branch and releases were a big part of my workload. But I'm sure gitlab will all automate that.

What you describe I also figured out for myself (mirror on a rpi4 with SSD, with a VPN thrown in for remote access to the mirror server for weekends and from work), but with my remaining commits mostly not related much to each other, creating, learning and maintaining such a shadow infrastructure is simply not worth it. 

 

TinyPortal © 2005-2018