This will remember the credentials for an hour after which Git operations will
This remembers the credentials for an hour, after which Git operations
require re-authentication.
If you are using OS X you can use `osxkeychain` to store and encrypt your credentials.
...
...
@@ -258,7 +265,7 @@ If you are storing LFS files outside of GitLab you can disable LFS on the projec
It is possible to host LFS objects externally by setting a custom LFS URL with `git config -f .lfsconfig lfs.url https://example.com/<project>.git/info/lfs`.
You might choose to do this if you are using an appliance like a Sonatype Nexus to store LFS data. If you choose to use an external LFS store,
GitLab will not be able to verify LFS objects which means that pushes will fail if you have GitLab LFS support enabled.
You might choose to do this if you are using an appliance like a <!-- vale gitlab.Spelling = NO --> Sonatype Nexus <!-- vale gitlab.Spelling = YES --> to store LFS data. If you choose to use an external LFS store,
GitLab can't verify LFS objects. Pushes then fail if you have GitLab LFS support enabled.
To stop push failure, LFS support can be disabled in the [Project settings](../../../user/project/settings/index.md). This means you will lose GitLab LFS value-adds (Verifying LFS objects, UI integration for LFS).
To stop push failure, LFS support can be disabled in the [Project settings](../../../user/project/settings/index.md), which also disables GitLab LFS value-adds (Verifying LFS objects, UI integration for LFS).
Since Git Annex files are stored in a sub-directory of the normal repositories
(`.git/annex/objects`) and LFS files are stored outside of the repositories,
they are not compatible as they are using a different scheme. Therefore, the
Git Annex files are stored in a sub-directory of the normal repositories
(`.git/annex/objects`) and LFS files are stored outside of the repositories.
The two aren't compatible as they are using a different scheme. Therefore, the
migration has to be done manually per repository.
There are basically two steps you need to take in order to migrate from Git
...
...
@@ -74,17 +74,17 @@ Fire up a terminal, navigate to your Git repository and:
### Disabling Git Annex in your repository
Before changing anything, make sure you have a backup of your repository first.
There are a couple of ways to do that, but you can simply clone it to another
There are a couple of ways to do that, but you can clone it to another
local path and maybe push it to GitLab if you want a remote backup as well.
Here you'll find a guide on
[how to back up a **git-annex** repository to an external hard drive](https://www.thomas-krenn.com/en/wiki/Git-annex_Repository_on_an_External_Hard_Drive).
A guide on
[how to back up a **git-annex** repository to an external hard drive](https://www.thomas-krenn.com/en/wiki/Git-annex_Repository_on_an_External_Hard_Drive) is also available.
Since Annex files are stored as objects with symlinks and cannot be directly
Because Annex files are stored as objects with symlinks and cannot be directly
modified, we need to first remove those symlinks.
NOTE:
Make sure the you read about the [`direct` mode](https://git-annex.branchable.com/direct_mode/) as it contains
useful information that may fit in your use case. Note that `annex direct` is
information that may fit in your use case. The `annex direct` command is
deprecated in Git Annex version 6, so you may need to upgrade your repository
if the server also has Git Annex 6 installed. Read more in the
- (Blog Post) [Getting Started with Git FLS](https://about.gitlab.com/blog/2017/01/30/getting-started-with-git-lfs-tutorial/)
- (Blog Post) [Announcing LFS Support in GitLab](https://about.gitlab.com/blog/2015/11/23/announcing-git-lfs-support-in-gitlab/)
- (Blog Post) [GitLab Annex Solves the Problem of Versioning Large Binaries with Git](https://about.gitlab.com/blog/2015/02/17/gitlab-annex-solves-the-problem-of-versioning-large-binaries-with-git/)
This is useful when you want to *hide* certain things - like secret keys,
passwords, SSH keys, etc. It is and should not be used to hide mistakes, as
it will make it harder to debug in case there are some other bugs. The main
reason for this is that you loose the real development progress. **Also keep in
passwords, and SSH keys. It is and should not be used to hide mistakes, as
it makes it harder to debug in case there are some other bugs. The main
reason for this is that you loose the real development progress. Keep in
mind that, even with modified history, commits are just detached and can still be
accessed through commit ID** - at least until all repositories perform
the cleanup of detached commits (happens automatically).
accessed through commit ID - at least until all repositories perform
the automated cleanup of detached commits.
...
...
@@ -404,16 +410,16 @@ the cleanup of detached commits (happens automatically).
Modified history breaks the development chain of other developers, as changed
history does not have matching commit IDs. For that reason it should not be
used on any public branch or on branch that *might* be used by other developers.
used on any public branch or on branch that might be used by other developers.
When contributing to big open source repositories (for example, [GitLab](https://gitlab.com/gitlab-org/gitlab/blob/master/CONTRIBUTING.md#contribution-acceptance-criteria)
itself), it is acceptable to *squash* commits into a single one, to present a
itself), it is acceptable to squash commits into a single one, to present a
nicer history of your contribution.
Keep in mind that this also removes the comments attached to certain commits
in merge requests, so if you need to retain traceability in GitLab, then
modifying history is not acceptable.
A feature-branch of a merge request is a public branch and might be used by
A featurebranch of a merge request is a public branch and might be used by
other developers, but project process and rules might allow or require
you to use `git rebase` (command that changes history) to reduce number of
displayed commits on target branch after reviews are done (for example
...
...
@@ -427,7 +433,7 @@ Never modify the commit history of `master` or shared branch.
### How modifying history is done
After you know what you want to modify (how far in history or how which range of
old commits), use `git rebase -i commit-id`. This command will then display all the commits from
old commits), use `git rebase -i commit-id`. This command displays all the commits from
current version to chosen commit ID and allow modification, squashing, deletion
expect(AuditEvent.last.details[:custom_message]).toeq("Created project access token with id: #{response.payload[:access_token].user.id} with scopes: #{response.payload[:access_token].scopes}")
expect(audit_event.details[:custom_message]).toeq("Created project access token with id: #{response.payload[:access_token].user.id} with scopes: #{response.payload[:access_token].scopes}")
@@ -93,7 +101,7 @@ RSpec.describe ResourceAccessTokens::CreateService do
it'logs the permission error message'do
subject
expect(AuditEvent.last.details[:custom_message]).toeq('Attempted to create project access token but failed with message: User does not have permission to create project access token')
expect(AuditEvent.where(author_id: user.id).last.details[:custom_message]).toeq('Attempted to create project access token but failed with message: User does not have permission to create project access token')
end
end
...
...
@@ -115,7 +123,7 @@ RSpec.describe ResourceAccessTokens::CreateService do
it'logs the provisioning error message'do
subject
expect(AuditEvent.last.details[:custom_message]).toeq('Attempted to create project access token but failed with message: Could not provision maintainer access to project access token')
expect(AuditEvent.where(author_id: user.id).last.details[:custom_message]).toeq('Attempted to create project access token but failed with message: Could not provision maintainer access to project access token')
@@ -48,7 +56,7 @@ RSpec.describe ResourceAccessTokens::RevokeService do
it'logs the find error message'do
subject
expect(AuditEvent.last.details[:custom_message]).tomatch(/Attempted to revoke project access token with id: \d+, but failed with message: Failed to find bot user/)
expect(AuditEvent.where(author_id: user.id).last.details[:custom_message]).tomatch(/Attempted to revoke project access token with id: \d+, but failed with message: Failed to find bot user/)
end
end
...
...
@@ -63,7 +71,7 @@ RSpec.describe ResourceAccessTokens::RevokeService do
it'logs the permission error message'do
subject
expect(AuditEvent.last.details[:custom_message]).tomatch(/Attempted to revoke project access token with id: \d+, but failed with message: #{user.name} cannot delete #{access_token.user.name}/)
expect(AuditEvent.where(author_id: user.id).last.details[:custom_message]).tomatch(/Attempted to revoke project access token with id: \d+, but failed with message: #{user.name} cannot delete #{access_token.user.name}/)
