In e23a26a (and later 1bc9936) the API for Gitlab::LDAP::Adapter was
changed. I assume this rake task was an oversight in the refactoring of
the changed class.
While being on it, I noticed that already blocked users cannot be
blocked again.
If project has open merge request from fork and this fork was removed
before merge request was closed it cause exception during push
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
Better merge request manual instructions
I noticed the current instructions for manually merging a merge request that was submitted from a fork could create unnecessary merge requests or strange history. Imagine this:
1. Alice creates a repository and commits / pushes a single commit with SHA1 `A` to `master`.
2. Bob forks this repository and creates a new branch `myfeature` on `master` (`A`)
3. Alice commits `B` to `master` (which has the parent `A`)
4. Bob creates two commits on `myfeature` `P` and `Q`.
5. Bob submits the merge request to merge his `myfeature` into Alice's `master` branch.
6. Alice follows the manual merge request instructions:
1. `git checkout -b bob/repo-myfeature master`
2. `git pull http://... myfeature`
The branch `bob/repo-myfeature` was created from Alice's current `master`, which was `B`. When the `pull` is executed, git will fetch Bob's branch and then merged the fetched branch `Q` into the current branch's location `B`. This creates an unnecessary merge commit from `master` into the branch Alice is trying to merge. No harm is done, but the history is a bit messier.
This is even worse if Alice has set `git pull` to rebase by default. In this case, the commit `B` is rebased on top of `Q`. When Alice checks out `master` and merges in the branch, there will actually be a duplicate `B` commit.
These new instructions instead tell the user to fetch Bob's `myfeature` branch. This will fetch the necessary commits `P` and `Q` and create a temporary ref `FETCH_HEAD` pointing to `Q`. Alice will then create her local `bob/repo-myfeature` branch starting at `FETCH_HEAD`. No unnecessary merge commits, and no accidental rebasing.
See merge request !16
Don't enable IPv4 *only* on nginx.
I came across this issue when initially setting up gitlab and fixed it locally. Today, helping someone else set up their own instance, I came across this issue again:
The sample nginx configuration files disable IPv6 by default, making the server inaccesible unless the remote node has native IPv4. IPv4->IPv6 transition mechanisms don't help if the server have proper IPv6 DNS records in-place, which was the case for both of my servers.
This branch enables IPv4 and IPv6 by default. Older servers with no external IPv6 connectivity will not fail since they'll have a local-link IPv6 address to bind to anyway.
See merge request !231
Marvin Frick
Dmitriy Zaporozhets
Marin Jankovski
Dmitriy Zaporozhets
Valery Sizov
Drew Blessing
Ben Bodenmiller
Nikita Verkhovin
Marin Jankovski
skv
Valery Sizov
