Recent

Author Topic: Branches  (Read 1083 times)

SymbolicFrank

  • Hero Member
  • *****
  • Posts: 1050
Branches
« 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?

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 8101
  • Debugger - SynEdit - and more
    • wiki
Re: Branches
« Reply #1 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.

SymbolicFrank

  • Hero Member
  • *****
  • Posts: 1050
Re: Branches
« Reply #2 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.

Thausand

  • Sr. Member
  • ****
  • Posts: 282
Re: Branches
« Reply #3 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.

  • On the top bar, select Menu > Project.
  • Select your fork of the repository.
  • On the left menu, go to Merge requests, and select New merge request. (*)
  • In the Source branch drop-down list box, select the branch in your forked repository as the source branch.
  • In the Target branch drop-down list box, select the branch from the upstream repository as the target branch. You can set a default target project to change the default target branch (which can be useful if you are working in a forked project).
  • Select Compare branches and continue.
  • Select Submit merge request.

(*) 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  :)
« Last Edit: July 05, 2022, 11:53:52 am by Thausand »

SymbolicFrank

  • Hero Member
  • *****
  • Posts: 1050
Re: Branches
« Reply #4 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?
« Last Edit: July 05, 2022, 12:21:00 pm by SymbolicFrank »

Thausand

  • Sr. Member
  • ****
  • Posts: 282
Re: Branches
« Reply #5 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.
« Last Edit: July 05, 2022, 12:41:37 pm by Thausand »

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 8101
  • Debugger - SynEdit - and more
    • wiki
Re: Branches
« Reply #6 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.



SymbolicFrank

  • Hero Member
  • *****
  • Posts: 1050
Re: Branches
« Reply #7 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.
« Last Edit: July 05, 2022, 01:23:29 pm by SymbolicFrank »

Thausand

  • Sr. Member
  • ****
  • Posts: 282
Re: Branches
« Reply #8 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  :'(
« Last Edit: July 05, 2022, 01:48:57 pm by Thausand »

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 8101
  • Debugger - SynEdit - and more
    • wiki
Re: Branches
« Reply #9 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.

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 8101
  • Debugger - SynEdit - and more
    • wiki
Re: Branches
« Reply #10 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.

SymbolicFrank

  • Hero Member
  • *****
  • Posts: 1050
Re: Branches
« Reply #11 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).
« Last Edit: July 05, 2022, 01:52:50 pm by SymbolicFrank »

SymbolicFrank

  • Hero Member
  • *****
  • Posts: 1050
Re: Branches
« Reply #12 on: July 05, 2022, 01:58:22 pm »
Can I just make it public, or does that allow everyone to change things?

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 8101
  • Debugger - SynEdit - and more
    • wiki
Re: Branches
« Reply #13 on: July 05, 2022, 02:03:18 pm »
public on gitlab is just read access.

For write access you need to invite people.

Thausand

  • Sr. Member
  • ****
  • Posts: 282
Re: Branches
« Reply #14 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.

 

TinyPortal © 2005-2018