Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GitLab 8.5 released

about.gitlab.com

Post reply on HN
Print view View original

31–40 of 246 posts

Re: GitLab 8.5 released

#31

Post by dom96 »

jobvandervoort wrote: post #22
jobvandervoort wrote: post #17

Earlier quoted context omitted.

If you move your repository by importing it (in GitLab UI, under new project) or just by clone + pushing it yourself, you will always retain your entire commit history.

If you import from GitHub, your issues, PRs, wiki and all code will be imported.

It would be really cool if GitHub stored issue, PR, and wiki information in the main Git repo. That way all of these things would be very easy to keep in sync across different services.

I've had this idea for a while now. I wonder if it would be practical and if anyone has ever tried something like this.

Re: GitLab 8.5 released

#32

Post by jobvandervoort »

whitenoice wrote: post #30

Impressive release! Is there a guide on migrating from install from source to using omnibus? We currently upgrade from source but would like to move to omnibus.

Thanks!

To upgrade from source to omnibus: https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/doc...

To see all our update guides: https://about.gitlab.com/update/

Re: GitLab 8.5 released

#33

Post by Ensorceled »

pilif wrote: post #27
Ensorceled wrote: post #23

Earlier quoted context omitted.

Nitpick on the nitpick. If the Git blobs were the source of the memory leak then this would, in fact, fix the memory leaks. Pretty aggressive stance when you may, in fact, be wrong.

> If the Git blobs were the source of the memory leak then this would, in fact, fix the memory leaks. no. Because they are still reading git blobs - just only for the smaller files. > GitLab no longer loads large Git blobs (e.g. binary files) into memory [emphasis mine] So if their handling of Git blobs is leaking memory, then not reading the bigger blobs just gives them more leeway before they crash.

Again, you may still be wrong. Many systems have different strategies for large blobs vs. small blobs (I know it's many because I've written several myself) including chunking strategies, separate memory pools etc.

I'm taking this stand because I've had the exact issue we are arguing about: my large file handler had a leak in the memory pool for large blobs. Basically it was shared memory space for multiple processes so large objects could be passed out of band instead of using IO.

Re: GitLab 8.5 released

#34

Post by jobvandervoort »

lars_francke wrote: post #28
jobvandervoort wrote: post #13

Earlier quoted context omitted.

That's correct.

Thanks for that. Can you give us details on when this change will happen?

We're not sure yet when it will happen, but we'll make it clear when we do.

Update: our aim is before Q1 ends.

Re: GitLab 8.5 released

#35

Post by icebraining »

dom96 wrote: post #31
jobvandervoort wrote: post #22

Earlier quoted context omitted.

If you import from GitHub, your issues, PRs, wiki and all code will be imported.

It would be really cool if GitHub stored issue, PR, and wiki information in the main Git repo. That way all of these things would be very easy to keep in sync across different services. I've had this idea for a while now. I wonder if it would be practical and if anyone has ever tried something like this.

That's what Joey Hess' github-backup does: https://github.com/joeyh/github-backup

It's one way, though, you can't create a new Issue or PR by just updating repo.

Re: GitLab 8.5 released

#36

Post by iBotPeaches »

whitenoice wrote: post #30

Impressive release! Is there a guide on migrating from install from source to using omnibus? We currently upgrade from source but would like to move to omnibus.

Warning as someone who just did that. MySQL is EE only on Omnibus. I switched from Source (MySQL) to Omnibus only to find that MySQL was EE only.

So I had to go back to Source.

Re: GitLab 8.5 released

#37

Post by mbrock »

dom96 wrote: post #31
jobvandervoort wrote: post #22

Earlier quoted context omitted.

If you import from GitHub, your issues, PRs, wiki and all code will be imported.

It would be really cool if GitHub stored issue, PR, and wiki information in the main Git repo. That way all of these things would be very easy to keep in sync across different services. I've had this idea for a while now. I wonder if it would be practical and if anyone has ever tried something like this.

As a separate root branch, it would work nicely. There are huge benefits also in that you get an inspectable history of issues. From GitHub's perspective, it would be more difficult to authenticate issue changes—they'd need signed commits and pre push validation, right?

Re: GitLab 8.5 released

#38

Post by branchly2 »

When I go to github, there's a search bar at the top to search for the public repo I'm looking for.

I can't find the search feature at gitlab.com. How do I search for users or public repos of interest at gitlab?

Re: GitLab 8.5 released

#39

Post by ausjke »

Still using redmine + gitolite here but have been watching Gitlab for a while, in fact I tried it yesterday and it's still quite resource hungry and slow(using DO's default installation with 1GB memory).

Redmine+Gitolite has nearly everything I need but Gitlab's code view interface is better. Redmine's backend seems running more efficiently but its interface is not modern enough at this point, especially on how to review git repos.

Re: GitLab 8.5 released

#40

Post by ones_and_zeros »

pilif wrote: post #3

Nitpick: > GitLab no longer loads large Git blobs (e.g. binary files) into memory when browsing a Git repository. This prevents timeouts and memory leaks. Nope. Not loading something doesn't prevent memory leaks. It might make existing leaks not as bad (because you're leaking less). Either you're not leaking at which point it doesn't matter how big the thing you load is, it will get freed once it's not used, or you'r…

I think you can be a bit more charitable in your interpretation.

Think of it this way: By no longer loading large Git blobs, it prevents known memory leaks and prevents known timeouts.

Post reply on HN