21–30 of 246 posts
Earlier quoted context omitted.
What procedures did you follow to move your private repos over? I have been using private, self hosted git for years now. Were you able to move things over and keep commit history? (since I guess that's the only feature I currently have.)
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.
Earlier quoted context omitted.
What procedures did you follow to move your private repos over? I have been using private, self hosted git for years now. Were you able to move things over and keep commit history? (since I guess that's the only feature I currently have.)
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.
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…
Pretty aggressive stance when you may, in fact, be wrong.
Earlier quoted context omitted.
It seems not, unfortunately, I'm sorry if you were waiting for it. I'll discuss if we can ship it in a patch [0], otherwise it'll land in a month in CE. [0]: https://gitlab.com/gitlab-org/gitlab-ce/issues/11489#note_38...
Thanks, Looking forward to it. otherwise, congrats on another release!
Consensus seems to be we can ship it somewhere this week.
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.
Is there an issue/PR migration path as well?
Docs here: http://doc.gitlab.com/ce/workflow/importing/import_projects_...
Earlier quoted context omitted.
What procedures did you follow to move your private repos over? I have been using private, self hosted git for years now. Were you able to move things over and keep commit history? (since I guess that's the only feature I currently have.)
I just added Gitlab as a new remote, and pushed. Easy as that. Keeps the entire repo history. I then just removed my old Github remotes.
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…
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.
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.
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…
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.