gofmt all files

Apparently the rules for comment formatting have changed with go 1.19.
This commit is contained in:
Michael Eischer 2022-08-19 19:12:26 +02:00
parent dbca93da28
commit f414db987d
10 changed files with 42 additions and 42 deletions

View File

@ -148,10 +148,10 @@ func parsePercentage(s string) (float64, error) {
// prepareCheckCache configures a special cache directory for check.
//
// * if --with-cache is specified, the default cache is used
// * if the user explicitly requested --no-cache, we don't use any cache
// * if the user provides --cache-dir, we use a cache in a temporary sub-directory of the specified directory and the sub-directory is deleted after the check
// * by default, we use a cache in a temporary directory that is deleted after the check
// - if --with-cache is specified, the default cache is used
// - if the user explicitly requested --no-cache, we don't use any cache
// - if the user provides --cache-dir, we use a cache in a temporary sub-directory of the specified directory and the sub-directory is deleted after the check
// - by default, we use a cache in a temporary directory that is deleted after the check
func prepareCheckCache(opts CheckOptions, gopts *GlobalOptions) (cleanup func()) {
cleanup = func() {}
if opts.WithCache {

View File

@ -8,7 +8,7 @@ import (
rtest "github.com/restic/restic/internal/test"
)
//TestFillSecondaryGlobalOpts tests valid and invalid data on fillSecondaryGlobalOpts-function
// TestFillSecondaryGlobalOpts tests valid and invalid data on fillSecondaryGlobalOpts-function
func TestFillSecondaryGlobalOpts(t *testing.T) {
//secondaryRepoTestCase defines a struct for test cases
type secondaryRepoTestCase struct {

2
doc.go
View File

@ -1,6 +1,6 @@
// Package restic gives a (very brief) introduction to the structure of source code.
//
// Overview
// # Overview
//
// The packages are structured so that cmd/ contains the main package for the
// restic binary, and internal/ contains almost all code in library form. We've

View File

@ -28,10 +28,10 @@ import (
// Backend stores data in a GCS bucket.
//
// The service account used to access the bucket must have these permissions:
// * storage.objects.create
// * storage.objects.delete
// * storage.objects.get
// * storage.objects.list
// - storage.objects.create
// - storage.objects.delete
// - storage.objects.get
// - storage.objects.list
type Backend struct {
gcsClient *storage.Client
projectID string

View File

@ -1,6 +1,6 @@
// Package test contains a test suite with benchmarks for restic backends.
//
// Overview
// # Overview
//
// For the test suite to work a few functions need to be implemented to create
// new config, create a backend, open it and run cleanup tasks afterwards. The
@ -10,10 +10,11 @@
// then the methods RunTests() and RunBenchmarks() can be used to run the
// individual tests and benchmarks as subtests/subbenchmarks.
//
// Example
// # Example
//
// Assuming a *Suite is returned by newTestSuite(), the tests and benchmarks
// can be run like this:
//
// func newTestSuite(t testing.TB) *test.Suite {
// return &test.Suite{
// Create: func(cfg interface{}) (restic.Backend, error) {
@ -33,7 +34,7 @@
//
// The functions are run in alphabetical order.
//
// Add new tests
// # Add new tests
//
// A new test or benchmark can be added by implementing a method on *Suite
// with the name starting with "Test" and a single *testing.T parameter for

View File

@ -2,7 +2,7 @@
// the following the abstractions used for this package are listed. More
// information can be found in the restic design document.
//
// File
// # File
//
// A file is a named handle for some data saved in the backend. For the local
// backend, this corresponds to actual files saved to disk. Usually, the SHA256
@ -11,18 +11,17 @@
// encrypted before being saved in a backend. This means that the name is the
// hash of the ciphertext.
//
// Blob
// # Blob
//
// A blob is a number of bytes that has a type (data or tree). Blobs are
// identified by an ID, which is the SHA256 hash of the blobs' contents. One or
// more blobs are bundled together in a Pack and then saved to the backend.
// Blobs are always encrypted before being bundled in a Pack.
//
// Pack
// # Pack
//
// A Pack is a File in the backend that contains one or more (encrypted) blobs,
// followed by a header at the end of the Pack. The header is encrypted and
// contains the ID, type, length and offset for each blob contained in the
// Pack.
//
package repository