| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
| |
Git v2.41.0 comes with [changes](https://github.com/git/git/commit/933e3a4ee205353d8f093d5dfcd226fa432c4e58)
that breaks go-git's assumptions for when detecting empty repositories.
Go-git expects a flush instead of the first hash line. Instead, a dummy capabilities^{}
with zero-id is returned. The change aims to allow for identifying
the object format even when cloning empty
repositories.
Signed-off-by: Paulo Gomes <pjbgf@linux.com>
|
|
|
|
|
|
|
|
| |
Some areas of the code base were missing error checks,
without them it may be harder to troubleshoot unexpected
behaviours.
Signed-off-by: Paulo Gomes <pjbgf@linux.com>
|
|
|
|
| |
Signed-off-by: Paulo Gomes <pjbgf@linux.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Azure DevOps requires capabilities multi_ack / multi_ack_detailed,
which are not fully implemented and by default are included in
transport.UnsupportedCapabilities.
The initial clone operations require a full download of the repository,
and therefore those unsupported capabilities are not as crucial, so
by removing them from that list allows for the first clone to work
successfully.
Additional fetches will yield issues, therefore to support that
repository users have to work from a clean clone until those
capabilities are fully supported. Commits and pushes back into the
repository have also been tested and work fine.
This change adds an example for cloning Azure DevOps repositories.
Signed-off-by: Paulo Gomes <pjbgf@linux.com>
|
|
|
|
| |
`GO_GIT_USER_AGENT_EXTRA` as the git user agent. Fixes #529
|
|
|
|
|
|
|
|
|
| |
value. (#521)
Previously, calling `Set($CAPABILITY, ...)` on a `capability.List` where `$CAPABILITY`
was already present would correctly replace the existing value of that capability, but
would also result in that capability being listed twice in the internal `l.sort` slice.
This manifested publicly when the `List` was encoded as the same capability appearing
twice with the same value in the encoded output.
|
|
|
| |
Signed-off-by: Carlos A Becker <caarlos0@gmail.com>
|
|\
| |
| | |
Remove unused vars/types/funcs/fields
|
| |
| |
| |
| |
| |
| |
| |
| | |
[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.
|
|\ \ |
|
| |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Per the [Go Spec](https://go.dev/ref/spec#Constant_declarations),
the following yields the type `Action` for `Bar` and `Baz`
only if there is no `=`.
const (
Foo Action = ...
Bar
Baz
)
The following has the type `Action` for the first item,
but not the rest. Those are untyped constants
of the corresponding type.
const (
Foo Action = ...
Bar = ...
Baz = ...
)
This means that `packp.{Update, Delete, Invalid}` are currently
untyped string constants, and not `Action` constants
as was intended here.
This change fixes these.
|
|/
|
|
|
|
| |
push --atomic allows a push to succeed or fail atomically. If one ref
fails, the whole push fails. This commit allows the user to set Atomic
as an option for a push.
|
|
|
|
| |
go-git: Add field `Options` to `PushOptions`, wire functionality.
|
| |
|
|
|
|
| |
* plumbing: protocol/packp, Adding object-format and filter capabilities. Fixes #220
|
|\
| |
| | |
*: minor linter fixes
|
| | |
|
|/ |
|
| |
|
| |
|
| |
|
|
|
|
| |
Signed-off-by: Oleksandr Redko <oleksandr.red+github@gmail.com>
|
|
|
|
|
|
|
| |
No need to convert these values, they're already of the right type.
Signed-off-by: Christian Muehlhaeuser <muesli@gmail.com>
(cherry picked from commit a1d8a7ac8bd0e4aff0f27dbb8bb37b8bd13a1346)
|
|
|
|
| |
Signed-off-by: Antonio Jesus Navarro Perez <antnavper@gmail.com>
|
|
|
|
|
|
|
|
|
|
| |
- no length for map initialization
- don't check for boolean/error return
- don't format string
- use string method of bytes buffer instead of converting bytes to
string
- use `strings.Contains` instead of `strings.Index`
- use `bytes.Equal` instead of `bytes.Compare`
|
| |
|
|
|
|
| |
Fixes #623
|
| |
|
| |
|
|\
| |
| | |
plumbing: protocol, fix handling multiple ACK on upload-pack and test…
|
| | |
|
|\ \
| |/
|/| |
improve delete support on push
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
* server: implement delete-refs and announce it.
* remote: check if server announced delete-refs before trying
to delete and fail fast if it does not.
Note that the client does not need no send 'delete-refs' back
to the server to be able to delete references:
```
delete-refs
-----------
If the server sends back the 'delete-refs' capability, it means that
it is capable of accepting a zero-id value as the target
value of a reference update. It is not sent back by the client, it
simply informs the client that it can be sent zero-id values
to delete references.
```
So our server implementation does not check if the client sent
delete-refs back, it just accepts deletes if it receives them.
|
|/ |
|
|
|
|
|
|
|
|
|
| |
GitHub has started using a non-standard capability "early-capabilities"
with agent=git/github-g3daa19f21. This is breaking all go-git operations
on GitHub.
This commit removes validation for known capabilities, so that we can
use non-standard capabilities safely.
|
|
|
|
| |
To be able to fix #261 we will move again to gopkg.in before v4 stable release.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* server: add generic server implementation (transport-independent),
both for git-upload-pack and git-receive-pack.
* server: move internal functions to internal/common.
* cli: add git-receive-pack and git-upload-pack implementations.
* format/packfile: add UpdateObjectStorage function, extracted from
Remote.
* transport: implement tranport RPC-like, only with git-upload-pack and
git-receive-pack methods. Client renamed to Transport.
* storer: add storer.Storer interface.
* protocol/packp: add UploadPackResponse constructor with packfile.
* protocol/packp: fix UploadPackResponse encoding, add tests.
* protocol/packp/capability: implement All.
|
|
|
|
|
|
|
|
|
|
|
|
| |
* remote: add Push.
* add Push method to Remote.
* add method Push to Repository.
* examples: add push example.
* requested changes
* add tests, fixes
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
* protocol/packp: add Packfile field to ReferenceUpdateRequest.
* protocol/packp: add NewReferenceUpdateRequestFromCapabilities.
* NewReferenceUpdateRequestFromCapabilities can be used to create
a ReferenceUpdateRequest with initial capabilities compatible with
the server.
* protocol/packp: fix new line handling on report status.
* transport/file: test error on unexisting command.
|
|
|
|
|
|
| |
git 1.8 used to write a leading space in the capabilities
announcement for git-receive-pack. We now trim spaces before
decoding a capabilities list to be more tolerant about
this kind of difference.
|