| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | | |\ \ \ \ \ \ |
|
| | | |\ \ \ \ \ \ \ |
|
| | | | | | | | | | | |
|
| | |\ \ \ \ \ \ \ \ \
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
Annotate models
Time to refresh the comments via `annotate`.
See merge request !2311
|
| | | | | | | | | | | | |
|
| | | |_|_|_|_|_|/ / /
| |/| | | | | | | |
| | | | | | | | | |
| | | | | | | | | | |
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
|
| | | | | | | | | | | |
|
| | |\ \ \ \ \ \ \ \ \
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
Get "Merge when build succeeds" to work when commits were pushed to MR
target branch while builds were running
The Merge when build succeeds service only merges when the MR is
mergeable (open, not WIP, no conflicts).
When the target branch is updated, all affected MRs have their merge
status set to `unchecked`, and the conflicts check will only happen
when `check_if_can_be_merged` is called, which happens when the MR page
is viewed.
When someone enables the automatic merge, the target branch is updated,
no-one views the MR page again, and the build succeeds, the mergeability
check will fail and the MR will not in fact be merged.
This MR makes sure `check_if_can_be_merged` is always called when MR
mergeability is checked.
See merge request !2304
|
| | | |\ \ \ \ \ \ \ \ \
| | | | |_|_|_|_|/ / /
| | | |/| | | | | | | |
|
| | | | |_|_|_|_|/ / /
| | |/| | | | | | |
| | | | | | | | | |
| | | | | | | | | | |
target branch while builds were running
|
| | |\ \ \ \ \ \ \ \ \
| | |_|_|/ / / / / /
| |/| | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | | |
Fix mentionable reference extraction caching.
Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/4130
Reverts https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/2120 and https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/2283
See merge request !2315
|
| | | | |/ / / / / /
| | |/| | | | | | |
|
| | |\ \ \ \ \ \ \ \
| | |/ / / / / / /
| |/| | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
Fix project destroy callback
See gitlab-org/gitlab-ee!107.
See merge request !2307
|
| | | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
See gitlab-org/gitlab-ee!107.
|
| | |\ \ \ \ \ \ \ \
| | |/ / / / / / /
| |/| | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
Validate README format
Take the first previewable README file as project's README, otherwise if
none file is available, or we can't preview any of them, we assume that
project doesn't have a README file.
Fixes #3978
|
| | | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
Take the first previewable README file as project’s README, otherwise
if none file is available, or we can’t preview any of them, we assume
that project doesn’t have a README file.
|
| | |\ \ \ \ \ \ \ \
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | | |
Better support for referencing and closing issues in asana_service.rb (by @mikew1)
See merge request !2302
|
| | | | | | | | | | | |
|
| | | |\ \ \ \ \ \ \ \
| | | | |_|_|_|_|/ /
| | | |/| | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | | |
* upstream/master: (307 commits)
Update CHANGELOG
spinach fix
Updated allocations Gem to version 1.0.3
Removed various default metrics tags
Update CHANGELOG
Fix "I see current user as the first user" step
Swap Author and Assignee Selectors on issuable index view
Update CHANGELOG
Make sure that is no pending migrations in Gitlab::CurrentSettings
Added additional config environmental variables to help Debian packaging
We don't use whenever anymore. Lets remove the schedule file
Fix project transfer e-mail sending incorrect paths in e-mail notification
Update CHANGELOG
Use Gitlab::CurrentSettings for InfluxDB
Write to InfluxDB directly via UDP
Strip newlines from obfuscated SQL
Add hotfix that allows to access build artifacts created before 8.3
note votes methids implementation
When reCAPTCHA is disabled, allow registrations to go through without a code
Downcased user or email search for avatar_icon.
...
|
| | | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | | |
[ci skip]
|
| | | | | | | | | | | |
|
| | | | | | | | | | | |
|
| | | |\ \ \ \ \ \ \ \
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
* origin/master:
Use lazy reference extractor to get issue's MRs
Banzai::XFilter -> Banzai::Filter::XFilter
Move Markdown/reference logic from Gitlab::Markdown to Banzai
|
| | | | | | | | | | | | |
|
| | | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
requests to Asana API
|
| | | | | | | | | | | | |
|
| | | | | | | | | | | | |
|
| | |\ \ \ \ \ \ \ \ \ \
| | |_|_|_|_|/ / / / /
| |/| | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
Add graphs of commits ahead/behind default branch (by @brunsa2)
Replaces https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/1716
See merge request !2301
|
| | | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
Rugged seemed to stop accepting branch names as valid refs, throwing `Rugged::ReferenceError` exceptions. Now the branch target rather than branch name is used, and the default branch's hash is also calculated, and these work properly.
This used to work and might be something worth re-investigating in the future.
|
| | | |\ \ \ \ \ \ \ \ \ |
|
| | | |\ \ \ \ \ \ \ \ \ \ |
|
| | | | | | | | | | | | | | |
|
| | | | | | | | | | | | | | |
|
| | | |_|_|_|_|_|/ / / / /
| |/| | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | | |
Tell, Don't Ask.
|
| | |\ \ \ \ \ \ \ \ \ \ \
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | | |
Prevent duplicate "username has already been taken" validation message
Closes #201 - two-year-old bug, woo! :boom: :tada:
See merge request !2279
|
| | | | |_|_|_|_|/ / / / /
| | |/| | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | | |
Closes #201 - two-year-old bug, woo! :boom: :tada:
|
| | |\ \ \ \ \ \ \ \ \ \ \
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | | |
Added system hooks messages for renaming and transferring a project
This is work in progress but I wanted to get some feedback on it in case there is something I've missed or a better way to do it.
As the title says when a project is renamed or transferred to another group a system hook message is generated.
Currently adds a couple of extra properties to the standard project system hooks messages.
old_path_with_namespace - The old path of the project so we can see what has been renamed / transferred
changed_at - The time that change took place
My main concern is if there is a better way of doing this than passing the extra_data variable into the system hook. Would it be better to extend the project model with these 2 items as transient properties as I doubt they would need to be saved to the database? The other
I've also seen, but can't find, someone talking about the emails sent when a project is renamed or transferred doesn't reference the original project path so if you have similarly named projects then you might not know what has been moved. I think the extra_data (or however it is best to implement this) would allow the extra information to be sent in emails.
Closes [System hooks for project transfer and repository rename](http://feedback.gitlab.com/forums/176466-general/suggestions/6006233-system-hooks-for-project-transfer-and-repository-r)
See merge request !611
|
| | | |/ / / / / / / / / / |
|
| | |/ / / / / / / / / / |
|
| |/ / / / / / / / / / |
|
| |\ \ \ \ \ \ \ \ \ \
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
Hotfix for builds trace data integrity
Closes #4246
See merge request !2224
|
| | | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
This is a temporary hotfix that allows to access build artifacts created
before 8.3. See #5257.
This needs to be changed after migrating CI build files.
Note that `ArtifactUploader` uses `artifacts_path` to create a storage
directory before and after parsisting `Ci::Build` instance, before and
after moving a file to store (save and fetch a file).
|
| | | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
Issue #4246
|
| | | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
The introduction of ActiveJob and `deliver_now` in 7f214cee7 caused a race
condition where the mailer would be invoked before the project was committed
to the database, causing the transfer e-mail notification to show the old
path instead of the new one.
Closes #4670
|
| |\ \ \ \ \ \ \ \ \ \ \
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | | |
Revert upvotes and downvotes params back to MR API
issue https://gitlab.com/gitlab-org/gitlab-ce/issues/3672
See merge request !2212
|
| | | | | | | | | | | | | |
|
| | | | | | | | | | | | | |
|
| | |_|_|_|_|_|_|_|_|_|/
|/| | | | | | | | | | |
|
| |\ \ \ \ \ \ \ \ \ \ \
| |_|/ / / / / / / / /
|/| | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
Disable --follow in `git log` to avoid loading duplicate commit data in infinite scroll
`git` doesn't work properly when `--follow` and `--skip` are specified together. We could even be **omitting commits in the Web log** as a result.
Here are the gory details. Let's say you ran:
```
git log -n=5 --skip=2 README
```
This is the working case since it omits `--follow`. This is what happens:
1. `git` starts at `HEAD` and traverses down the tree until it finds the top-most commit relevant to README.
2. Once this is found, this commit is returned via `get_revision_1()`.
3. If the `skip_count` is positive, decrement and repeat step 2. Otherwise go onto step 4.
4. `show_log()` gets called with that commit.
5. Repeat step 1 until we have all five entries.
That's exactly what we want. What happens when you use `--follow`? You have to understand how step 1 is performed:
* When you specify a pathspec on the command-line (e.g. README), a flag `prune` [gets set here](https://github.com/git/git/blob/master/revision.c#L2351).
* If the `prune` flag is active, `get_commit_action()` determines whether the commit should be [scanned for matching paths](https://github.com/git/git/blob/master/revision.c#L2989).
* In the case of `--follow`, however, `prune` is [disabled here](https://github.com/git/git/blob/master/revision.c#L2350).
* As a result, a commit is never scanned for matching paths and therefore never pruned. `HEAD` will always get returned as the first commit, even if it's not relevant to the README.
* Making matters worse, the `--skip` in the example above would actually skip a every other entry after `HEAD` N times. If README were changed in these skipped commits, we would actually miss information!
Since git uses a matching algorithm to determine whether a file was renamed, I
believe `git` needs to generate a diff of each commit to do this and traverse
each commit one-by-one to do this. I think that's the rationale for disabling
the `prune` functionality since you can't just do a simple string comparison.
Closes #4181, #4229, #3574, #2410
See merge request !2210
|
| | | |_|_|_|_|_|_|/ /
| |/| | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | | |
infinite scroll
`git` doesn't work properly when `--follow` and `--skip` are specified together. We could even be **omitting commits in the Web log** as a result.
Here are the gory details. Let's say you ran:
```
git log -n=5 --skip=2 README
```
This is the working case since it omits `--follow`. This is what happens:
1. `git` starts at `HEAD` and traverses down the tree until it finds the top-most commit relevant to README.
2. Once this is found, this commit is returned via `get_revision_1()`.
3. If the `skip_count` is positive, decrement and repeat step 2. Otherwise go onto step 4.
4. `show_log()` gets called with that commit.
5. Repeat step 1 until we have all five entries.
That's exactly what we want. What happens when you use `--follow`? You have to understand how step 1 is performed:
* When you specify a pathspec on the command-line (e.g. README), a flag `prune` [gets set here](https://github.com/git/git/blob/master/revision.c#L2351).
* If the `prune` flag is active, `get_commit_action()` determines whether the commit should be [scanned for matching paths](https://github.com/git/git/blob/master/revision.c#L2989).
* In the case of `--follow`, however, `prune` is [disabled here](https://github.com/git/git/blob/master/revision.c#L2350).
* As a result, a commit is never scanned for matching paths and therefore never pruned. `HEAD` will always get returned as the first commit, even if it's not relevant to the README.
* Making matters worse, the `--skip` in the example above would actually skip every other after `HEAD` N times. If README were changed in these skipped commits, we would actually miss information!
Since git uses a matching algorithm to determine whether a file was renamed, I
believe `git` needs to generate a diff of each commit to do this and traverse
each commit one-by-one to do this. I think that's the rationale for disabling
the `prune` functionality since you can't just do a simple string comparison.
Closes #4181, #4229, #3574, #2410
|
