* Show namespace thumbnail differently if project was already forked
* Show loading spinner when click on fork
* Fork link navigates to personal namespace only if no manageable groups exists
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
Now you can fork project into group or personal namespace.
Also I moved fork logic from ProjectsController to own fork resource
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
Add a password strength indicator to SIGN UP and PROFILE pages
Fixes#1647
Added a password strength indicator to the sign up page. You can see how it looks in the following screenshot. In the sign up page, it checks if the password contains the username and alerts the user about it. If the user still wants to proceed with creating his account, nothing will stop him. This is merely a message. The indicator changes the input background color based on the strength like this:
The password strength indicator can also be found in the profile edit page. It functions in almost the exact same way, with the exception that it doesn't check if the password contains the username.
There are tests included.
/cc @job
See merge request !1227
Dmitriy Zaporozhets
Dmitriy Zaporozhets
Marin Jankovski
Nikita Verkhovin
skv
Valeriy Sizov
Sean Edge
Patricio Cano
Drew Blessing
Ben Bodenmiller
Ciro Santilli
Robert Schilling
Sytse Sijbrandij
