| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Signed-off-by: Arieh Schneier <15041913+AriehSchneier@users.noreply.github.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Clone remote as a mirror. This fetches all remote refs, implies bare
repository, and sets the appropriate configs.
Fixes: https://github.com/go-git/go-git/issues/293
Update options.go
Co-authored-by: Paulo Gomes <paulo.gomes.uk@gmail.com>
Signed-off-by: Ayman Bagabas <ayman.bagabas@gmail.com>
|
|
|
|
|
|
| |
Relates to the SHA256 implementation, defined in #706.
Signed-off-by: Paulo Gomes <pjbgf@linux.com>
|
|
|
|
| |
Signed-off-by: Paulo Gomes <pjbgf@linux.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When fs.Stat returns an error, pathinfo may be nil. In such situations
the only safe response seems to be to return the error to the caller.
Without this fix, accessing pathinfo.IsDir() below would lead to a crash
dereferencing a nil pointer.
This crash can be reproduced by trying to initialize a Git repo with an
invalid path name.
Also see: https://github.com/muesli/gitty/issues/36
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
| |
|
|
|
|
| |
github.com/ProtonMail/go-crypto/openpgp (#283)
|
|
|
|
|
| |
This PR add insecureSkipTLSVerify and cabundle to any remote http calls
so that https repo with private CA signed can be used. This is the
equivalent of https.sslVerify and GIT_SSL_CAINFO
|
| |
|
| |
|
|\
| |
| | |
*: minor linter fixes
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |
|
| |
|
| |
|
|
|
|
| |
Signed-off-by: Saeed Rasooli <saeed.gnu@gmail.com>
|
|
|
|
|
|
| |
keep NewCommitFileIterFromIter for compatibilty for now
Signed-off-by: Saeed Rasooli <saeed.gnu@gmail.com>
|
|
|
|
| |
Signed-off-by: knqyf263 <knqyf263@gmail.com>
|
|
|
|
| |
Signed-off-by: Valentin Cocaud <v.cocaud@gmail.com>
|
|
|
|
|
|
|
|
|
|
| |
1) lookups on an annotated tag oid now work
2) there was a lot of complexity around detection of ambiguity, but
unlike git, ambiguous refs are rejected (which causes bugs like
#823). The new code matches rev-parse's behavior (prefer the OID),
though there is no warning path to report the same warning.
Signed-off-by: Mike Lundy <mike@fluffypenguin.org>
|
|
|
|
| |
Signed-off-by: niukuo <niukuo@gmail.com>
|
|
|
|
| |
Signed-off-by: kuba-- <kuba@sourced.tech>
|
|
|
|
| |
Signed-off-by: kuba-- <kuba@sourced.tech>
|
|
|
|
|
|
|
|
| |
Previously the error message when the connection was closed while
fetching was "object not found" and was misleading. Now when the
packfile size is 0 the error "unable to fetch packfile" is returned.
Signed-off-by: Javi Fontan <jfontan@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
| |
PR #1008 introduced a regression by changing the errors returned by
PlainClone when a repository did not exist.
This change goes back to returned errors as they were in v4.7.0.
Fixes #1027
Signed-off-by: Santiago M. Mola <santi@mola.io>
|
|
|
|
| |
Signed-off-by: Fedor Korotkov <fedor.korotkov@gmail.com>
|
|
|
|
| |
Signed-off-by: Santiago M. Mola <santi@mola.io>
|
|
|
|
| |
Signed-off-by: Bartek Jaroszewski <jaroszewskibartek@gmail.com>
|
|\
| |
| | |
repository: allow open non-bare repositories as bare
|
| |
| |
| |
| | |
Signed-off-by: Máximo Cuadros <mcuadros@gmail.com>
|
|\ \ |
|
| |\ \
| | | |
| | | | |
Use remote name in fetch while clone
|
| | | |
| | | |
| | | |
| | | | |
Signed-off-by: Máximo Cuadros <mcuadros@gmail.com>
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Fixes #827
Signed-off-by: Dustin Frisch <fooker@lab.sh>
|
| | |/
| |/|
| | | |
plumbing: object, Add support for Log with filenames. Fixes #826
|
| |\ \ |
|
| | | |
| | | |
| | | |
| | | | |
Signed-off-by: kuba-- <kuba@sourced.tech>
|
| | | |
| | | |
| | | |
| | | | |
Signed-off-by: Javi Fontan <jfontan@gmail.com>
|
| | | |
| | | |
| | | |
| | | | |
Signed-off-by: Javi Fontan <jfontan@gmail.com>
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Also adds Static configuration to Storage and DotGit. This option means
that the git repository is not expected to be modified while open and
enables some optimizations.
Each time a file is accessed the storer tries to open an object file for
the requested hash. When this is done for a lot of objects it is
expensive. With Static option a list of object files is generated the
first time an object is accessed and used to check if exists instead of
using system calls.
A similar optimization is done for packfiles.
Signed-off-by: Javi Fontan <jfontan@gmail.com>
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Just renaming the TagObjectOptions type to CreateTagOptions so that it's
consistent with the other option types.
Signed-off-by: Chris Marchesi <chrism@vancluevertech.com>
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Deleting a tag ref for an annotated tag in normal git behavior does not
delete the tag object right away. This is handled by the normal GC
process.
Signed-off-by: Chris Marchesi <chrism@vancluevertech.com>
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This is to avoid any ambiguity with the act of "fetching" in git in
general.
Signed-off-by: Chris Marchesi <chrism@vancluevertech.com>
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
I've mainly noticed that in using the current Tag function, that there
were lots of times that I was ignoring the ref or the object, depending
on what I needed. This was evident in the tests as well. As such, I
think it just makes more sense for a singular tag fetcher to return just
a ref, through which the caller may grab the annotation if they need it,
and if it exists.
Also, contrary to the docs on Tags, all tags have a ref, even if they
are annotated. The difference between a lightweight tag and an annotated
tag is the presence of the tag object, which the ref will point to if
the tag is annotated. As such I've adjusted the docs with an example as
to how one can get the annotation for a tag ref through the iterator.
Source: https://git-scm.com/book/en/v2/Git-Internals-Git-References,
tags section.
Signed-off-by: Chris Marchesi <chrism@vancluevertech.com>
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
I figured there was a way to do this without having to have
TagObjectOptions supply this in - there is.
Added support for this in and removed the object type from
TagObjectOptions.
Signed-off-by: Chris Marchesi <chrism@vancluevertech.com>
|