Recent

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

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9794
  • Debugger - SynEdit - and more
    • wiki
Re: FPC & Lazarus moving to gitlab
« Reply #60 on: June 25, 2021, 05:31:37 pm »
But it might perhaps be good to consider a GIT commit hook script to magically create a kind of revision number or sequence that is a bit more human readable than the normal GIT hashes. And can be used as a reference.
"git describe"

But tags need to be created yet

DonAlfredo

  • Hero Member
  • *****
  • Posts: 1739
Re: FPC & Lazarus moving to gitlab
« Reply #61 on: June 25, 2021, 05:55:13 pm »
Quote
But tags need to be created yet
Yep. Looked into this, but its not trivial to be honest. However, tags seem to be the only way to get something that resembles sequential release info that is a bit human readable. I can fully imagine/understand that this will not be implemented, but its worth investigating.

DonAlfredo

  • Hero Member
  • *****
  • Posts: 1739
Re: FPC & Lazarus moving to gitlab
« Reply #62 on: June 25, 2021, 06:09:29 pm »
In addition to the above.
As the current GIT repo of FPC trunk has the SVN release tags available, fpcupdeluxe allows its users to input a SVN revision. This revision will be searched for in the GIT logs, and converted into a GIT hash that is used to checkout the desired revision/commit.
So, the extra info that is put into future GIT-tags must be suitable for checkouts of the desired revision/commit. If not, tags are of no use IMHO.

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9794
  • Debugger - SynEdit - and more
    • wiki
Re: FPC & Lazarus moving to gitlab
« Reply #63 on: June 25, 2021, 06:10:43 pm »
Quote
But tags need to be created yet
Yep. Looked into this, but its not trivial to be honest. However, tags seem to be the only way to get something that resembles sequential release info that is a bit human readable. I can fully imagine/understand that this will not be implemented, but its worth investigating.
I already did tests, should be easy.

But final details are not ready yet.

af0815

  • Hero Member
  • *****
  • Posts: 1289
Re: FPC & Lazarus moving to gitlab
« Reply #64 on: June 25, 2021, 07:11:02 pm »
Question for Benchmarkig:
How did other git using projects handle this ? Eg. Linux-Kernel. Create a mimik from a svn workflow will complicate things in git.

Is this possible to use with a history. Eg. https://githowto.com/aliases and https://githowto.com/getting_old_versions . This produce a list with date and a shorten hash. The shorten hash with date can IMHO used like a tag inside a branch. If you use a master/develop modell you have a stable history for master and develop branch.

Short:
git config --global alias.hist "log --pretty=format:'%h %ad | %s%d [%an]' --graph --date=short"
or
git config --global alias.hist "log --pretty=format:'%h %ad | %s%d [%an]' --date=short"

git hist

The git hist show you nearly all you want without hacks
my 2 cents
« Last Edit: June 25, 2021, 07:12:37 pm by af0815 »
regards
Andreas

Bi0T1N

  • Jr. Member
  • **
  • Posts: 85
Re: FPC & Lazarus moving to gitlab
« Reply #65 on: June 26, 2021, 12:20:35 am »
As somebody who is not a core developer and has no (immediate) need to use Git or a Git-oriented hosting service for anything other than getting a current (.zip) snapshot, continued involvement with Trunk is tangential to everything else that I'm trying to do. In particular, I am not prepared to get myself into a situation where some needed facility of Trunk suddenly turns out to be broken, where if I want it to be fixed I've got to triage the release history myself, and where I find I can't easily revert to an older version because the .lpi or .lfm format has changed and I need a working Trunk to massage it back to a compatible format.
I don't see your problem. Instead of numbers you've hashes now but all of what you mentioned also works with hashes ;)
  • Generate SSH key pair
  • Then clone the trunk branch (or whatever it'll be named) to your local machine (needs only be done once): git clone git@gitlab.com:freepascal.org/fpc/<finalname>.git
  • Now you've a local copy which has everything the "remote" branch has
  • Create your own local branch: git checkout -b my_trunk_25062021 or git switch -c my_trunk_25062021
  • git automatically switches to the new branch you created (you can see that with git branch)
  • Now compile your FPC version and have fun
  • After some time you might want to move to the updated "remote" branch, so you switch to the trunk branch with git checkout trunk or git switch trunk, run git pull and create your new my_trunk_<futuredate> branch as above and compile your FPC
  • If you notice a problem, you scroll through git log and then you could checkout each commit with the commit hash shown in the log. The command(s) for the checkout are the already known command(s) checkout/switch. You can also easily see all changes between two branches with git diff branch1..branch2 (same also works with commit hashes)
However, it would be nice if the FPC devs would consider appending the (short) commit hash to the output of the compiler version like its done now: Free Pascal Compiler version 3.3.1-r49285 [2021/04/28] for x86_64.

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.
For doing small changes (stuff that don't really need to be tested like typos or other trivial things) Gitlab has the big advantage of the Web IDE (actually you can even compile there if it's setup). It is also possible to browse the code from the web browser (desktop and mobile).
And for the multiple machines, why don't you fork the project and push your changes to your user repository? Then you have your 'local' remote branch that can easily be shared (you only need internet access on all machines).


Well, what I really wanted to add is:
  • It should be considered to provide templates for different types of issues (default one for merge requests as well?), see here.
  • It might be better to assign the created issues to the appropriate milestone instead of adding labels like Version 3.2.0. I mean you've the milestones with the versions but don't assign any issues. The label is no longer required.
  • Providing a editorconfig file would help to have less problems with indentation and so on of people contributing code
  • The .gitignore file could be shrinked by using wildcards as this would simplify much of it: e.g. with *.exe *.o *.ppu all (sub)directories are automatically included
  • I don't think that every file should be listed in the .gitattributes file. This increases just the filesize (> 1MB) for no benefit since it can also be done with wildcards and it'll also don't mess up like this:
Code: Text  [Select][+][-]
  1. compiler/aarch64/ncpucnv.pas svneol=native#text/plain <- plain
  2. compiler/aarch64/ncpucon.pas svneol=native#text/pascal <- pascal
  3. compiler/aarch64/ncpuflw.pas svneol=native#text/pascal
  4. ...
  5. compiler/aarch64/ncpuset.pas svneol=native#text/plain <- plain
  6. compiler/aarch64/ra64con.inc svneol=native#text/plain
  7. compiler/aarch64/ra64dwa.inc svneol=native#text/plain

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: FPC & Lazarus moving to gitlab
« Reply #66 on: June 26, 2021, 09:54:11 am »
As somebody who is not a core developer and has no (immediate) need to use Git or a Git-oriented hosting service for anything other than getting a current (.zip) snapshot, continued involvement with Trunk is tangential to everything else that I'm trying to do. In particular, I am not prepared to get myself into a situation where some needed facility of Trunk suddenly turns out to be broken, where if I want it to be fixed I've got to triage the release history myself, and where I find I can't easily revert to an older version because the .lpi or .lfm format has changed and I need a working Trunk to massage it back to a compatible format.
I don't see your problem. Instead of numbers you've hashes now but all of what you mentioned also works with hashes ;)

Read the full thread before commenting. Sequential numbering doesn't work.

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

PascalDragon

  • Hero Member
  • *****
  • Posts: 5446
  • Compiler Developer
Re: FPC & Lazarus moving to gitlab
« Reply #67 on: June 26, 2021, 10:45:41 am »
  • It might be better to assign the created issues to the appropriate milestone instead of adding labels like Version 3.2.0. I mean you've the milestones with the versions but don't assign any issues. The label is no longer required.

The versions are the milestones, we don't consider anything else.

  • Providing a editorconfig file would help to have less problems with indentation and so on of people contributing code

Different parts of the project use different coding styles (e.g. compiler vs. RTL vs. packages). And this will not change.

  • The .gitignore file could be shrinked by using wildcards as this would simplify much of it: e.g. with *.exe *.o *.ppu all (sub)directories are automatically included

We have excluded those files and directories by experience. It's not enough to exclude selected files, because what is placed in e.g. the units directory might differ: If I should test something that outputs an additional file during compilation I don't want the whole bunch of units directories to pop up in git status.

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9794
  • Debugger - SynEdit - and more
    • wiki
Re: FPC & Lazarus moving to gitlab
« Reply #68 on: June 26, 2021, 11:53:54 am »
  • The .gitignore file could be shrinked by using wildcards as this would simplify much of it: e.g. with *.exe *.o *.ppu all (sub)directories are automatically included

We have excluded those files and directories by experience. It's not enough to exclude selected files, because what is placed in e.g. the units directory might differ: If I should test something that outputs an additional file during compilation I don't want the whole bunch of units directories to pop up in git status.

1) For those who are not aware. Private ignores, that do not need to be commited in .gitignore
./.git/info/exclude

2) I do not know what will go in there. But again there may be interesting patterns

On by private git, I do use

**/test/**/*.log

** in this dir, or any subdir

Therefore, in any test dir (any where deep inside the workdir)
Ignore any file (nested dir or not), that has a .log extension

Bi0T1N

  • Jr. Member
  • **
  • Posts: 85
Re: FPC & Lazarus moving to gitlab
« Reply #69 on: June 26, 2021, 01:43:25 pm »
As somebody who is not a core developer and has no (immediate) need to use Git or a Git-oriented hosting service for anything other than getting a current (.zip) snapshot, continued involvement with Trunk is tangential to everything else that I'm trying to do. In particular, I am not prepared to get myself into a situation where some needed facility of Trunk suddenly turns out to be broken, where if I want it to be fixed I've got to triage the release history myself, and where I find I can't easily revert to an older version because the .lpi or .lfm format has changed and I need a working Trunk to massage it back to a compatible format.
I don't see your problem. Instead of numbers you've hashes now but all of what you mentioned also works with hashes ;)

Read the full thread before commenting. Sequential numbering doesn't work.
I did and I explained to you that it does but just in the 'git' way where numbers == hashes. You can't expect to get the same output with a complete different principle. Don't try to see everything through a 'svn' view.

  • It might be better to assign the created issues to the appropriate milestone instead of adding labels like Version 3.2.0. I mean you've the milestones with the versions but don't assign any issues. The label is no longer required.

The versions are the milestones, we don't consider anything else.
Not sure if you understood what I meant. If you go to the Milestones, you'll notice that no issues are assigned to them. Instead every issue has a label that indicates the version it belongs to. That's not really following the general 'Gitlab principle'.

  • Providing a editorconfig file would help to have less problems with indentation and so on of people contributing code

Different parts of the project use different coding styles (e.g. compiler vs. RTL vs. packages). And this will not change.
Didn't said that but some units e.g. might use tab size of 2 and others using 4. This could be individually configured with the EditorConfig.

  • The .gitignore file could be shrinked by using wildcards as this would simplify much of it: e.g. with *.exe *.o *.ppu all (sub)directories are automatically included

We have excluded those files and directories by experience. It's not enough to exclude selected files, because what is placed in e.g. the units directory might differ: If I should test something that outputs an additional file during compilation I don't want the whole bunch of units directories to pop up in git status.
If you scroll through the .gitignore file you should notice that it always list the file extensions .exe, .o and .ppu which is kinda nonsense as you could use wildcards which will block them as well. If you want to commit and track single files of these types, just add this explicitly to the gitignore.

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11383
  • FPC developer.
Re: FPC & Lazarus moving to gitlab
« Reply #70 on: June 26, 2021, 02:02:49 pm »
( I pile it on a bit to make the point that not everybody sees this as an improvement)

For doing small changes (stuff that don't really need to be tested like typos or other trivial things) Gitlab has the big advantage of the Web IDE (actually you can even compile there if it's setup). It is also possible to browse the code from the web browser (desktop and mobile).

FPC has had a compile test before commiting (now pushing I assume) for a long time. But it would be useful for things like docs,  readmes etc.

But it is not a solution to anything development related. I can understand this if you are collaborating on a 50 lines script with a friend next door, but I do hope most projects have rules about making sure that main is always compiling. CI/Jenkins should only be to catch the leftover mistakes, not laziness.

(that said, in a work environment, CI solutions to check compiling work much easier, but that is because the guy breaking it is usually easily contacted, in the same room/building or at least at the keyboard for the rest of the working day, it is different with 24x7 projects done in spare time)

Quote
And for the multiple machines, why don't you fork the project and push your changes to your user repository? Then you have your 'local' remote branch that can easily be shared (you only need internet access on all machines).

So that I have push everything twice? So when I complain that  add+push all the time is more complicated than "commit" you suggest a solution with add+push+push ? Sigh.

You can have own repos on a rpi with branching etc with VPN, but new software is usually about improving workflow and reducing configuration and maintenance. Not doubling the whole infrastructure at the first workaround

Not about creating and maintaining a complete shadow server infrastructure, and even then clicking through 20 freaking questions while installing tortoisegit+git separately (tortoisesvn unified and only 3 questions) and even then having to do additional "git config"s.

Stone age junk software.

Quote
  • It might be better to assign the created issues to the appropriate milestone instead of adding labels like Version 3.2.0. I mean you've the milestones with the versions but don't assign any issues. The label is no longer required.

It would be nice. If milestones were actually clear up front. But in practice what goes into a fixes branch is often only finally decided in the weeks before branching. This because many people work on features in their own pace, which makes it hard to plan due to both technical and real life setbacks. 

« Last Edit: June 26, 2021, 02:12:27 pm by marcov »

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9794
  • Debugger - SynEdit - and more
    • wiki
Re: FPC & Lazarus moving to gitlab
« Reply #71 on: June 26, 2021, 02:36:38 pm »
Lets just establish a bit common ground here.

To use git, one has to break with old habits. And "old habits die hard".

The value of doing that, depends on what you get back.
I am an experienced git user (and I feel very confident to put it that way).
Yet, I have always and totally independent of this current discussion, stood the point: There are use cases where svn is the better choice for a person, or even a project.
And yes, I am taking into account all the fancy stuff that git offers. In some situation that does not add value.

"The binford 6100 is not needed to hang a picture"

Of course all the above, is not really helpful here.
The projects move. That's a done fact.
But just because people have to live with that, does not mean we need to convince them they are wrong. We may try to explore if they have sufficient information for their judgment, and offer it. But once we done that, we should have the capacity to accept an individuals judgment about their own situation in this.


Also, I have put a lot of time, into the specifics of moving to git for Lazarus. And there are many details that need very close attention being paid to them.
It's not a "one weekend to move to git" conversion. It's a lot more under the hood.

I wont go into all the details. But it's a lot. And it does affect everyone in the team.

Maybe in a year, we will know if we did a good job. And hopefully we will have done.
« Last Edit: June 26, 2021, 02:45:27 pm by Martin_fr »

af0815

  • Hero Member
  • *****
  • Posts: 1289
Re: FPC & Lazarus moving to gitlab
« Reply #72 on: June 26, 2021, 03:44:22 pm »
Lets just establish a bit common ground here.

To use git, one has to break with old habits. And "old habits die hard".
+1
regards
Andreas

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: FPC & Lazarus moving to gitlab
« Reply #73 on: June 26, 2021, 04:34:00 pm »
Lets just establish a bit common ground here.

To use git, one has to break with old habits. And "old habits die hard".
+1

Absolutely. But breaking habits can take resources, and on occasion one has to make decisions based on cost vs benefit.

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

PascalDragon

  • Hero Member
  • *****
  • Posts: 5446
  • Compiler Developer
Re: FPC & Lazarus moving to gitlab
« Reply #74 on: June 27, 2021, 12:57:03 pm »
  • It might be better to assign the created issues to the appropriate milestone instead of adding labels like Version 3.2.0. I mean you've the milestones with the versions but don't assign any issues. The label is no longer required.

The versions are the milestones, we don't consider anything else.
Not sure if you understood what I meant. If you go to the Milestones, you'll notice that no issues are assigned to them. Instead every issue has a label that indicates the version it belongs to. That's not really following the general 'Gitlab principle'.

And who said that we care about the "Gitlab principle"? We are doing this as we see fit and not how some website thinks is the way it should work. If we'll never use these milestones then we'll simply never use them.

  • Providing a editorconfig file would help to have less problems with indentation and so on of people contributing code

Different parts of the project use different coding styles (e.g. compiler vs. RTL vs. packages). And this will not change.
Didn't said that but some units e.g. might use tab size of 2 and others using 4. This could be individually configured with the EditorConfig.

If you consider it so important then provide patches for it.

  • The .gitignore file could be shrinked by using wildcards as this would simplify much of it: e.g. with *.exe *.o *.ppu all (sub)directories are automatically included

We have excluded those files and directories by experience. It's not enough to exclude selected files, because what is placed in e.g. the units directory might differ: If I should test something that outputs an additional file during compilation I don't want the whole bunch of units directories to pop up in git status.
If you scroll through the .gitignore file you should notice that it always list the file extensions .exe, .o and .ppu which is kinda nonsense as you could use wildcards which will block them as well. If you want to commit and track single files of these types, just add this explicitly to the gitignore.

It turned out (after we had a similar discussion on the core mailing list) that I looked at the .gitignore file in the SVN repository and not the one contained in the conversions as I consider the former the master. And there it's a much more compact file. I agree that what was generated by the conversion (by using the svn:ignore properties) is bad and in my opinion we should stick with the hand craft one.

 

TinyPortal © 2005-2018