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.

From the Go specification:

> "1. For a nil slice, the number of iterations is 0."
https://go.dev/ref/spec#For_range

Therefore, an additional nil check for before the loop is unnecessary.

Signed-off-by: Eng Zer Jun <engzerjun@gmail.com>

Currently gitea shows no commit information for files starting with a
colon.

[I set up a minimal repro repository that reproduces this error once
it's migrated on gitea](https://github.com/kbolashev/colon-test)

<img width="1209" alt="image"
src="https://user-images.githubusercontent.com/111061261/219326625-0e6d3a86-8b58-4d67-bc24-8a78963f36b9.png">

This is happening because the filenames piped to the `git log` command
are written as is, and it doesn't work when you have a colon at the
start of the filename, and you need to escape it.


You can test it locally,  if you do
```
mkdir repo
git init
touch :file 
git add . && git commit -m "Add file with colon"
git log -- :file 
```
git log returns nothing. However, if you do `git log -- "\:file"`, it
will show the commit with the file change.

This PR escapes the starting colons in paths in the `LogNameStatusRepo`
function, making gitea return commit info about the file with the bad
filename.

<img width="1209" alt="image"
src="https://user-images.githubusercontent.com/111061261/219328299-46451246-4006-45e3-89b1-c244635ded23.png">

This error shows up only with files starting with colon, anywhere else
in filename is ok. Dashes at the beginning also seem to be working.
I don't know gitea internals well enough to know where else this error
can pop up, so I'm keeping this PR small as suggested by your
contributor guide

Change all license headers to comply with REUSE specification.

Fix #16132

Co-authored-by: flynnnnnnnnnn <flynnnnnnnnnn@github>
Co-authored-by: John Olheiser <john.olheiser@gmail.com>

Follow #21464

Make all git command arguments strictly safe. Most changes are one-to-one replacing, keep all existing logic.

This PR adds a generic set type to get rid of maps used as sets.

Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>

The LastCommitCache code is a little complex and there is unnecessary
duplication between the gogit and nogogit variants.

This PR adds the LastCommitCache as a field to the git.Repository and
pre-creates it in the ReferencesGit helpers etc. There has been some
simplification and unification of the variant code.

Signed-off-by: Andrew Thornton <art27@cantab.net>

* Prevent context deadline error propagation in GetCommitsInfo

Although `WalkGitLog` tries to test for `context.DeadlineExceededErr`
there is a small chance that the error will propagate to the reader
before it is recognised. This will cause the error to propagate up to
`renderDirectoryFiles` and cause a http status 500.

Here we check that the error passed is a `DeadlineExceededErr` via error.Is

Fix #20329

Signed-off-by: Andrew Thornton <art27@cantab.net>

Follows #19266, #8553, Close #18553, now there are only three `Run..(&RunOpts{})` functions.
 * before: `stdout, err := RunInDir(path)`
 * now: `stdout, _, err := RunStdString(&git.RunOpts{Dir:path})`

Change all `cmd...Pipeline` commands to `cmd.RunWithContext`.

#18553

Co-authored-by: Martin Scholz <martin.scholz@versasec.com>

There is a slight race in checking of a context deadline exceed in #16467
which leads to a 500 on the repository page.

The solution is to check the error coming back from `*LogNameStatusRepoParser.Next()`
and if it is the `ContextDeadlineExceeded` break from the loop.

Fix #17314

Signed-off-by: Andrew Thornton <art27@cantab.net>

One of the biggest reasons for slow repository browsing is that we wait
until last commit information has been generated for all files in the
repository.

This PR proposes deferring this generation to a new POST endpoint that
does the look up outside of the main page request.

Signed-off-by: Andrew Thornton <art27@cantab.net>

When the external context is cancelled it is possible for the
GitLogReader to not itself be Closed.

This PR does three things:

1. Instead of adding a plain defer it wraps the `g.Close` in a func as
`g` may change.
2. It adds the missing explicit g.Close - although the defer fix makes
this unnecessary.
3. It passes down the external context as the base context for the
GitLogReader meaning that the cancellation of the external context will
pass down automatically.

Fix #17007

Signed-off-by: Andrew Thornton <art27@cantab.net>

* Improve get last commit using git log --name-status

git log --name-status -c provides information about the diff between a
commit and its parents. Using this and adjusting the algorithm to use
the first change to a path allows for a much faster generation of commit
info.

There is a subtle change in the results generated but this will cause
the results to more closely match those from elsewhere.

Signed-off-by: Andrew Thornton <art27@cantab.net>

Co-authored-by: 6543 <6543@obermui.de>
Co-authored-by: techknowlogick <techknowlogick@gitea.io>
Co-authored-by: Lauris BH <lauris@nix.lv>