github-forks
/
gitea
mirror of https://github.com/go-gitea/gitea.git
1
0
Fork 0
Code Projects Releases Activity
17,593 Commits
17 Branches
226 Tags
808 MiB
Commit Graph

5 Commits (82db9a2ba77d2a6c470b62be3c82b73c0a544fcc)

Author SHA1 Message Date
Adam Majer d68a613ba8
Add support for sha256 repositories () 
Currently only SHA1 repositories are supported by Gitea. This adds
support for alternate SHA256 with the additional aim of easier support
for additional hash types in the future.

Fixes: 
Limited by: https://github.com/go-git/go-git/issues/899
Depend on: 

<img width="776" alt="图片" src="https://github.com/go-gitea/gitea/assets/81045/5448c9a7-608e-4341-a149-5dd0069c9447">

---------

Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
Co-authored-by: 6543 <6543@obermui.de>
Lunny Xiao 4eb2a29910
Improve ObjectFormat interface () 
The 4 functions are duplicated, especially as interface methods. I think
we just need to keep `MustID` the only one and remove other 3.

```
MustID(b []byte) ObjectID
MustIDFromString(s string) ObjectID
NewID(b []byte) (ObjectID, error)
NewIDFromString(s string) (ObjectID, error)
```

Introduced the new interfrace method `ComputeHash` which will replace
the interface `HasherInterface`. Now we don't need to keep two
interfaces.

Reintroduced `git.NewIDFromString` and `git.MustIDFromString`. The new
function will detect the hash length to decide which objectformat of it.
If it's 40, then it's SHA1. If it's 64, then it's SHA256. This will be
right if the commitID is a full one. So the parameter should be always a
full commit id.

@AdamMajer Please review.
Lunny Xiao 408a484224
Adjust object format interface () 
- Remove `ObjectFormatID`
- Remove function `ObjectFormatFromID`.
- Use `Sha1ObjectFormat` directly but not a pointer because it's an
empty struct.
- Store `ObjectFormatName` in `repository` struct
wxiaoguang 9947af639c
Only use SHA256 feature when git >= 2.42 () 
And fix some comments
Adam Majer cbf923e87b
Abstract hash function usage () 
Refactor Hash interfaces and centralize hash function. This will allow
easier introduction of different hash function later on.

This forms the "no-op" part of the SHA256 enablement patch.