Recent

Author Topic: Branches  (Read 2325 times)

Martin_fr

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

 

SymbolicFrank

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


Martin_fr

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

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9792
  • Debugger - SynEdit - and more
    • wiki
Re: Branches
« Reply #18 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)
« Last Edit: July 05, 2022, 02:39:25 pm by Martin_fr »

SymbolicFrank

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

SymbolicFrank

  • Hero Member
  • *****
  • Posts: 1313
Re: Branches
« Reply #20 on: July 11, 2022, 12:24:39 pm »
Well, I created a branch with the changes, 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.

Martin_fr

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

SymbolicFrank

  • Hero Member
  • *****
  • Posts: 1313
Re: Branches
« Reply #22 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.)
« Last Edit: July 11, 2022, 02:11:00 pm by SymbolicFrank »

Martin_fr

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

SymbolicFrank

  • Hero Member
  • *****
  • Posts: 1313
Re: Branches
« Reply #24 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 ;)

SymbolicFrank

  • Hero Member
  • *****
  • Posts: 1313
Re: Branches
« Reply #25 on: July 11, 2022, 09:58:28 pm »
Michael has merged the branch :)

 

TinyPortal © 2005-2018