Lazarus

Free Pascal => General => Topic started by: SymbolicFrank on July 01, 2022, 02:28:22 pm

Title: Branches
Post by: SymbolicFrank on July 01, 2022, 02:28:22 pm
Say, you fixed some bugs and extended the functionality in some core packages. You report it on the bugtracker, but the priority is too low for it to be incorporated. So, you have a folder that contains not only the changed files, but also the ones it needs to compile.

After a while, the functionality of other files that have something to do with it changes in trunk. What do you do? Add all the needed files to your own branch until it compiles? Make patches for everything and run those after installing a new version?
Title: Re: Branches
Post by: Martin_fr on July 01, 2022, 03:43:29 pm
If you create your own git clone of the lazarus repo, then you can create your own branch.

That branch can then act as if it was a (series of) patch(es).
If upstream changes, you can rebase your branch.

rebasing, applies the individual commits as patches on the new target (new target = new upstream).

Most of the times, that works without conflicts. Of course if the same line is changed upstream, then you need to edit the file during the rebase.


As a side effect, if you have your changes in a branch on a cloned repo => then you can submit it as pull/merge-request. Making it easier to be incorporated.

If you do, duplicate the branch. If you rebase the branch, that also is a merge request, that makes the merge request harder to read.

If there are several individual changes/fixes, then ideally have them as individual commits. Helps to review them.
Title: Re: Branches
Post by: SymbolicFrank on July 05, 2022, 10:50:26 am
Ok. How do I create a merge request from the branch of my clone/fork to main? Gitlab doesn't like that.
Title: Re: Branches
Post by: Thausand on July 05, 2022, 11:49:21 am
Ok. How do I create a merge request from the branch of my clone/fork to main? Gitlab doesn't like that.

https://docs.gitlab.com/ee/user/project/merge_requests/creating_merge_requests.html

When you work in a fork

You can create a merge request from your fork to contribute back to the main project.


(*) have good look for not press up button merge request and use down merge request button. Up is merge own repository down is merge remote (upstream) repository

Oh I forgot say: when merge created then gitlab write need verify with credit card else get red cross for pipeline. Can ignore, it work  :)
Title: Re: Branches
Post by: SymbolicFrank on July 05, 2022, 12:17:31 pm
I did that (three times by now). The problem arises at step 5, where I cannot select the FPC/FPC Source repository. The only option for the target project is my own. I can fill in whatever I want, it gets ignored.

On second thought: it might be because I cloned it. I see there is a separate "fork" button. Can I fix that?
Title: Re: Branches
Post by: Thausand on July 05, 2022, 12:30:34 pm
OK, so make sure I/we understand:
You have not create fork with gitlab account ? but use clone with local git command ?

If is so, then that is problem.
a. Then you need create fork, then make changes from own repository to fork, then create merge.
or
b. make patch and upload patch to FPC issues

I think you not want b. and i not know better way for a.

link fork: https://docs.gitlab.com/ee/user/project/repository/forking_workflow.html
Quote
A fork is a personal copy of the repository and all its branches, which you create in a namespace of your choice. This way you can make changes in your own fork and submit them through a merge request to the repository you don’t have access to.
Title: Re: Branches
Post by: Martin_fr on July 05, 2022, 12:47:42 pm
How did you create your fork?
1) by pressing the fork button in the web interface of Gitlab?
2) by making a local clone, and then importing this to a new Gitlab.
3) by downloading sources, and creating a new git from it (not a fork)

In case of 1 it should work. 2, I have never tested.

In case of 1, when you go to "new merge" request, it should have one your branches pre-selected on the left, and one of the lazarus repo on the right.

In case of 2 see the post by Thausand.


Or never mind that... If it doesn't work, you can add a normal issue, with a link to your branch (and a note that gitlab didn't let you do a merge request). That would be a classic "pull request" => a request to pull your branch, and integrate it.
That is ok in case of 2, but not 3.
In case of 2 commits that came from the original repo, have the same sha1.

So when any dev pulls your branch, git will see the matching sha1, and it becomes a normal branch in their local repo.
I do that with most merge requests too, so I can test them before merging.

It's a bit more work for the developer, without a merge request, because your commits need to be changed, so the committer will be a developer (or they can't be pushed, due to security settings). Mind, only the committer. The author is kept as you.
So it depends who of us would be to look at them, and how git savvy that person is.


Title: Re: Branches
Post by: SymbolicFrank on July 05, 2022, 01:08:25 pm
I just made two new repositories on Gitlab and supplied the URL of FPC Source and Lazarus. And made a local clone of those, which do understand that they are linked to the remote one.

But half the idea is to keep things running while branches aren't merged yet, so I have to be able to pull the originals. And the idea of a Gitlab copy is to make it easy to create a merge request and check it out, right? So I can contribute my own fixes and improvements.

I'll probably have to redo everything in that case.

I always feel stupid when I have to work with Git-wrappers. I barely understand the internal logic of Git, if it comes to that. Ah, well, it works for Linus and we just have to get used to it, I guess.

I have enabled mirroring, but that doesn't work.
Title: Re: Branches
Post by: Thausand on July 05, 2022, 01:24:57 pm
@Martin_fr:
Thank for more information. Some projects not like when not have fork. good know FPC is ok with no fork.

But half the idea is to keep things running while branches aren't merged yet, so I have to be able to pull the originals.
Gitlab have mirror function to keep up date but is pay option. So we need do self:

edit: This is use when not have local copy on machine. Martin_fr write below write when have (always) local copy on machine

1. make local clone of fork project:
Code: [Select]
git clone https://gitlab.com/<username>/<repository.git>
2. update local clone of fork repository with upstream and push back (if is FPC source fork)
Code: [Select]
git remote add upstream https://gitlab.com/freepascal.org/fpc/source.git || true && git fetch upstream && git checkout main && git pull upstream main && git push origin main

Quote
And the idea of a Gitlab copy is to make it easy to create a merge request and check it out, right? So I can contribute my own fixes and improvements.
If want longer/more fixes then I think that better, yes.

Quote
I always feel stupid when I have to work with Git-wrappers. I barely understand the internal logic of Git, if it comes to that. Ah, well, it works for Linus and we just have to get used to it, I guess.
Stupid is wiki write about svn and mantis so not know what to do and figure out self. So please no make feel stupid yourself. I not know gitlab and have try 5/6 time before I understand  :'(
Title: Re: Branches
Post by: Martin_fr on July 05, 2022, 01:31:57 pm
But half the idea is to keep things running while branches aren't merged yet, so I have to be able to pull the originals. And the idea of a Gitlab copy is to make it easy to create a merge request and check it out, right? So I can contribute my own fixes and improvements.

The local clone of your fork can have several remotes.

Code: Bash  [Select][+][-]
  1. git remote add official   https://gitlab.com/freepascal.org/lazarus/lazarus.git

The default remote is called "origin".
You may have seen that when you referred to remote branches as origin/main.
Now you have origin/main and official/main.


Then you can specify the remote in git pull and push. They are also associated to branches, so once set up, you don't need to care.
Easiest to be done, with a GUI frontend.

Code: Bash  [Select][+][-]
  1. git pull origin

When you create a new branch
   git switch -c my-branch origin/main

you can push with
   git push origin
or
   git push origin my-branch


Afaik if you don't change it, origin will be your default push destination.
And you can't get it wrong, because you will get an error if you try to push to the original repo.
Title: Re: Branches
Post by: Martin_fr on July 05, 2022, 01:39:38 pm
I barely understand the internal logic of Git, if it comes to that.

If you have an SVN background... There are some wiki pages

https://wiki.lazarus.freepascal.org/FPC_git_concepts
A brief summary of the conceptual diff.

A command map
https://wiki.lazarus.freepascal.org/SVN_to_GIT_Cheatsheet

There is a 2nd command map. The above is the one I favour. The other is linked "alternative to this page", and the diff between them explained.
Title: Re: Branches
Post by: SymbolicFrank on July 05, 2022, 01:48:58 pm
@Thausand: The company I work for pays for it, we have all our other projects in there as well. So that's not the problem. But I enabled mirroring and it doesn't allow merge requests. So I have to redo them.

I get the idea behind Git, from Linus' point of view, but that isn't keeping source code safe and tracking changes. It's reducing the amount of changes that eventually reach him :)

We use Atlassian software (like most other companies) and I can rarely figure out how to do something there as well. So either the GUI of all that software is not intuitive at all, or they think that we want to do totally different things than we actually want  ;)

@Martin_fr: yes, I get that I can just check fpc out to a local copy, but don't I have to have a public copy somewhere for merge / pull requests? That was the reason to put it on Gitlab.

I do understand the concept behind Git, different repositories that you can sync through diffs, with a collection of diffs being a branch. It's the actual mechanics and naming that give me a headache. And I would rather use the command line that all those wrappers that try to make things "easy". Although Tortuise Git is fine.

I'll just try it again.

Edit: this is what I did (see picture).
Title: Re: Branches
Post by: SymbolicFrank on July 05, 2022, 01:58:22 pm
Can I just make it public, or does that allow everyone to change things?
Title: Re: Branches
Post by: Martin_fr on July 05, 2022, 02:03:18 pm
public on gitlab is just read access.

For write access you need to invite people.
Title: Re: Branches
Post by: Thausand on July 05, 2022, 02:04:48 pm
Can I just make it public, or does that allow everyone to change things?
You can make public. If not have private company secrets in repository.

Gitlab have option and protect repository. You need add other user to make change for your repository (sorry, I can not find gitlab page that explain. I know is there but can not find  :-[ ). Also when make merge request to upstream you can make option say not allow other user to change merge request.
Title: Re: Branches
Post by: Martin_fr on July 05, 2022, 02:20:40 pm
Bit off topic...
But just to illustrate: GitLab is not Git.  And Git is not Gitlab.

Git has no concept of a fork being something special, i.e. in the way that gitlab has some internal link between them.

For GIT a repo is a fork, if it has the same SHA. That is all. Unfortunately not for GitLab and GitHub. They add nice features. But they also restrict those feature to their own ideas...


Here is how well the actual GIT concept works (outside of GitLab).

In the old days, when SVN was still the official repo, there had been git-mirrors. Made by people who locally run git-svn or subgit, and who regularly pushed the converted data to GitHub/Lab.
There where 2 of them (that I know of). One be Graeme, one by me.

Those 2 were individually converted. They both had the same data, but the conversion run at a different time (a few minutes, an hour...), and by a different user => So commits ended up with different SHA1 (also commit messages differed by what was added to them, like "svn-id...").
Yet, if you cloned (via add remote) both those repo into the same local repo, then the local size on disk was that of just ONE of those two. (Well a very few bytes more).
So you had 2 gits, of each considerable size. Yet, you only needed the space for one of them.
Why?
Because the commits may have add different SHA1...
But the files, and folders inside were identical. And each file, each folder has it's own SHA1. So when git downloads the 2nd repo, it does immediately see, that it already has this file/folder. And it adds no storage. So this saving happens without git even needing to compress anything.

If you did a local fork, and pushed it, then even the commits (up to were your own commits start) have the same SHA1.
So if I pull from your repo, into my local git => git knows. simple as that.

Only GitLab does not know.... And so the gitlab merge-request does not work.
But a pull request works. Because a pull request is just a message (email, post, ....) that says: please pull the branch <name> from the repo <url>. And git can do that.

 
Title: Re: Branches
Post by: SymbolicFrank on July 05, 2022, 02:28:16 pm
Yes, it definitely is running another page of the book. Pet peeve: they want the private SSH key. That's stupid.

I forked FPC and... it created a new user, with a new billing plan.

To be continued...

Title: Re: Branches
Post by: Martin_fr on July 05, 2022, 02:28:39 pm
public on gitlab is just read access.

For write access you need to invite people.
Just mind, if you have (or even had) sensible data in a repo => "removing a branch" does not (for a few weeks) remove the date it held.

That is true for normal git and gitlab.
Git will hold on for I think 90 days (via something called reflog). I don't know the time for that on gitlab.

Content can still be accessed via the SHA1.
That can be either known, or gotten from the reflog, or "git fsck"

Ok, on gitlab you can't see the reflog or run fsck. (I have not tested, if fsck may work on a new clone...)
But Gitlab will add a message to your gitlab page when you delete a branch => and that has the SHA1. And with that, I can browse those commits on gitlab, and clone them if I want.


If you do need such commits purged urgently, then you need to contact gitlab support.

Best to never push anything that is "your eyes only".
Title: Re: Branches
Post by: Martin_fr on July 05, 2022, 02:36:13 pm
Yes, it definitely is running another page of the book. Pet peeve: they want the private SSH key. That's stupid.
Where does it say that?

Unless you mean, if you set up a push-mirror config, and you want gitlab to push into a non-gitlab git, that requires ssh auth. Then gitlab needs the credentials for that repo that it should push to. So then you create a key pair only for that use...

Quote
I forked FPC and... it created a new user, with a new billing plan.
Have a free account, and fork into the free account?

EDIT: "free project" or whatever the call it.
My account (i.e. login) has its own "project", free public repos (a Lazarus fork). And the same account is in the official Lazarus/fpc project, having access to all repos within, and occupying one and only one seat. (not that it matters, as it's an open source project and gets the seats for free)
Title: Re: Branches
Post by: SymbolicFrank on July 05, 2022, 02:41:35 pm
Yes, it was yet another account I probably made some time ago. I don't know why that was active, I never use it.
Title: Re: Branches
Post by: SymbolicFrank on July 11, 2022, 12:24:39 pm
Well, I created a branch with the changes (https://gitlab.com/frank.rademakers/fpc/-/commit/8b3a53371ca1ced71e1dd188d3a95ef4e9921faf), but I'm unable to make a merge request with the original FPC repository.

Then again, most things on GitLab fail unless I provide credit card details. That might be it.
Title: Re: Branches
Post by: Martin_fr on July 11, 2022, 01:48:27 pm
Strange. Gitlab definitely knows that your repo is related.
If I go to the fpc git, it allows me to make a merge request in the opposite direction: From fpc into your branch.

So it should work the other way round too.
I tried, I forked your repo, and captured the steps

If I then click "compare branches and continue", it lets me fill in a description, and shows 3 commits of yours that would be requested to merge.
Title: Re: Branches
Post by: SymbolicFrank on July 11, 2022, 02:09:21 pm
Ah, you're right. I clicked the merge request button on the submit. But I might have missed the link to change the branch.

But now it asks me to rebase. Did I miss a "pull" button somewhere?

(The first try to make a repository wasn't a fork, the second was a cherrypick. And I forgot to make a branch for making the submit. I hope I did everything right this time.)
Title: Re: Branches
Post by: Martin_fr on July 11, 2022, 03:46:07 pm
The merge request has been created. https://gitlab.com/freepascal.org/fpc/source/-/merge_requests/265

So, NO, don't rebase (at least not yet).

As far as I can see, it's a GitLab setting on the fpc repo (which I haven't used myself yet, so don't know all the details), that they will include merge-requests by rebase. So I expect someone from the fpc team will do the rebase.

If you did it now, then by the time they look at it, it would need to be rebased again.

I am guessing the green checkmark means that it can be rebased without conflict.
If that changes, then someone from the team will likely add a note, once they start looking at it.
Title: Re: Branches
Post by: SymbolicFrank on July 11, 2022, 04:11:54 pm
Ok. Sounds good :D

Yes, I suspected that an immediate rebase wouldn't help matters, so I didn't. But the Gitlab GUI could use some improvements ;)
Title: Re: Branches
Post by: SymbolicFrank on July 11, 2022, 09:58:28 pm
Michael has merged the branch :)
TinyPortal © 2005-2018