The variable length for plumbing.Hash is defined at build time, blocked by
tag sha256.
This approach was a trade-off between keeping backwards compatibility while
making progress towards supporting SHA256 with a small amount of changes.
Relates to the SHA256 implementation, defined in #706.
Signed-off-by: Paulo Gomes <pjbgf@linux.com>
In walkReferencesTree(), the filesystem is browsed recursively. After a folder
is listed, each child element (directory, file) are inspected.
What can happen is that by the time we get to operate on the child element, it
might have been deleted from the filesystem and we would get a PathError.
In the case of directories there was already a case to avoid bubbling up the error
(we consider that there is no ref there, which is correct), but that was missing
for files. This commit just apply the same logic.
The `os.SEEK_*` constants have been deprecated since Go 1.7.
It is now recommended to use the equivalent `io.Seek*` constants.
Switch `os.SEEK_CUR` to `io.SeekCurrent`,
and `os.SEEK_SET` to `io.SeekStart`.
Per [Go Code Review Comments][1],
> Error strings should not be capitalized (unless beginning with proper
> nouns or acronyms) or end with punctuation
staticcheck's [ST1005][2] also complains about these. For example,
```
object_walker.go:63:10: error strings should not be capitalized (ST1005)
object_walker.go:101:10: error strings should not be capitalized (ST1005)
object_walker.go:101:10: error strings should not end with punctuation or a newline (ST1005)
plumbing/format/commitgraph/file.go:17:26: error strings should not be capitalized (ST1005)
```
This fixes all instances of this issue reported by staticcheck.
[1]: https://github.com/golang/go/wiki/CodeReviewComments#error-strings
[2]: https://staticcheck.io/docs/checks/#ST1005
[staticcheck](https://staticcheck.io/) reported a number of unused
fields, functions, types, and variables across the code.
Where possible, use them (assert unchecked errors in tests, for example)
and otherwise remove them.
This PR adds code to prevent large objects from being read into memory
from packfiles or the filesystem.
Objects greater than 1Mb are now no longer directly stored in the cache
or read completely into memory.
This PR differs and improves the previous broken #323 by fixing several
bugs in the reader and transparently wrapping ReaderAt as a Reader.
Signed-off-by: Andrew Thornton <art27@cantab.net>
This PR adds code to prevent large objects from being read into memory from packfiles or the filesystem.
Objects greater than 1Mb are now no longer directly stored in the cache
or read completely into memory.
Signed-off-by: Andrew Thornton <art27@cantab.net>
Like `git rev-parse <prefix>`, this enumerates the hashes of objects
with the given prefix and adds them to the list of candidates for
resolution.
This has an exhaustive slow path, which requires enumerating all objects
and filtering each one, but also a couple of fast paths for common
cases. There's room for future work to make this faster; TODOs have been
left for that.
Fixes#135.
Git creates `.git/commondir` when there are custom worktrees (see "git worktree add" related commands).
`.git/commondir` in such case contains a link to another dot-git repository tree, which could contain some folders like:
- objects;
- config;
- refs;
- etc.
In this PR a new dotgit.RepositoryFilesystem struct is defined, which is billy.Filesystem interface compatible object-wrapper, that can handle commondir and dispatch all operations to the correct file path.
`git.PlainOpen` remain unchanged, but `git.PlainOpenWithOptions` has a new option: `PlainOpenOptions.EnableDotGitCommonDir=true|false` (which is false by default). When `EnableDotGitCommonDir=true` repository-open procedure will read `.git/commondir` (if it exists) and then create dotgit.RepositoryFilesystem object initialized with 2 filesystems. This object then passed into storage and then into dotgit.DotGit as `billy.Filesystem` interface. This object will catch all filesystem operations and dispatch to the correct repository-filesystem (dot-git or common-dot-git) according to the rules described in the doc: https://git-scm.com/docs/gitrepository-layout#Documentation/gitrepository-layout.txt. EnableDotGitCommonDir option will only work with the filesystem-backed storage.
Also worktree_test.go has been adopted from an older, already existing existing PR: https://github.com/src-d/go-git/pull/1098. This PR needs new fixtures added in the following PR: https://github.com/go-git/go-git-fixtures/pull/1.
On some operating systems, read() of a directory fd may actually succeed and
return garbage resembling on-disk contents. As a result, dotgit may return
successful from readReferenceFile() when it should in-fact not.
This fixes readReferenceFile() on FreeBSD.
Signed-off-by: Kyle Evans <kevans@FreeBSD.org>
Specifically, the problem demonstrated is that on some OS (e.g. FreeBSD),
read() on a directory will succeed. The current implementation will accept
that and return incorrect results, rather than rejecting the directory.
When we assign a value to err, make sure to also check for it being nil
afterwards. If those were intentionally unchecked, we should remove the
assignment in the first place. Those checks certainly never harm, but please
review thoroughly and let me know.
Signed-off-by: Christian Muehlhaeuser <muesli@gmail.com>
(cherry picked from commit 19d6f42a4d814a50bd262fbb69a9b670db9756a2)
The MaxOpenDescriptors option provides a middle ground solution between keeping
all packfiles open (as offered by the KeepDescriptors option) and keeping none
open.
Signed-off-by: Arran Walker <arran.walker@fiveturns.org>
Large performance increase by buffering reads.
There were a few instances where binary.Read() would end up using reflection on
&plumbing.Hash, rather than treating it as a byte slice. This has now been
resolved.
Signed-off-by: Arran Walker <arran.walker@fiveturns.org>
If the cache is shared between several repositories getFromUnpacked can
erroneously return an object from other repository.
This decreases performance a little bit as there's an extra fs operation
when the object is in the cache but is correct when the cache is shared.
Signed-off-by: Javi Fontan <jfontan@gmail.com>
