-
-
Notifications
You must be signed in to change notification settings - Fork 5.8k
Use native git variants by default with go-git variants as build tag #13673
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Current status of this PR:
|
As an example, prior to this PR running:
on the gitea would balloon in memory use. This no longer happens. |
Codecov Report
@@ Coverage Diff @@
## master #13673 +/- ##
==========================================
- Coverage 42.25% 42.20% -0.05%
==========================================
Files 697 700 +3
Lines 76596 76862 +266
==========================================
+ Hits 32363 32437 +74
- Misses 38919 39077 +158
- Partials 5314 5348 +34
Continue to review full report at Codecov.
|
How does this compare if |
Can't really read much in these images, does that include memory used by git processes or only gitea? What about performance wise? |
This is Gitea's memory. If you zoom in you will see that nogogit Gitea takes up 99.51Mb following the run but gogit Gitea takes up 240Mb. If you run the curl task again gogit will continue to increase. There's a memory leak somewhere. (And it's in the red tree to the left on the gogit tree) Peak memory usage for Gitea is higher with go-git than git - although I'm not completely able to assert this. Now this PR appears slightly slower in the getcommitpaths I will see if I can speed that up though and there's a bug I've noticed elsewhere. |
How about to move go-git related files to a sub directory and git-shell related to another sub directory if we cannot make all operations to an interface? |
@lunny that's the intended endpoint of this pr - once I've got the bugs ironed out and a more efficient getcommitpaths |
OK so the changes are slightly
The algorithm here is different and simply involves checking every commit. This is clearly not going to be the fastest solution but that I've managed to make it faster than the current algorithm suggests that even faster systems are possible.
|
Signed-off-by: Andrew Thornton <[email protected]>
Signed-off-by: Andrew Thornton <[email protected]>
Signed-off-by: Andrew Thornton <[email protected]>
Signed-off-by: Andrew Thornton <[email protected]>
Signed-off-by: Andrew Thornton <[email protected]>
Signed-off-by: Andrew Thornton <[email protected]>
Signed-off-by: Andrew Thornton <[email protected]>
Signed-off-by: Andrew Thornton <[email protected]>
Signed-off-by: Andrew Thornton <[email protected]>
Signed-off-by: Andrew Thornton <[email protected]>
Signed-off-by: Andrew Thornton <[email protected]>
Signed-off-by: Andrew Thornton <[email protected]>
Signed-off-by: Andrew Thornton <[email protected]>
@zeripath can you add one integration test for gogit? EDIT: so we make sure both implementations work - and we can switch to one or another depending on the need ;) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
as i can tell this is a huge imprvement
If I missed a bug I'm sorry - but I think we shoul get it in
Let's merge this at first even if maybe there are some missed. |
GOPROXY: https://goproxy.cn # proxy.golang.org is blocked in China, this proxy is not | ||
GOSUMDB: sum.golang.org | ||
TAGS: bindata gogit sqlite sqlite_unlock_notify | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry I'm late here but is it really necessary to run the linter twice here? Do TAGS
really affect the linting result? I thought TAGS
only affect the build.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess it's beyond me to understand how TAGS can affect linting (which should just be a static analysis of files). Care to explain? Does the go linter actually do runtime analysis as well?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
golangci-lint has a --build-tags
to support lint different tags.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok I guess I need to study golangci-lint
more. I was under the impression that linters in general just do static analysis of file contents, but I guess this linter does more than that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thought I generally wonder if it's really necessary to do this double linting every single CI run. The go linting already takes around 3 minutes per run.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The issue is that the go-git variants require linting too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can't we just pass a list of files to the linters as argument? I think it should be possible.
There is a slight bug in the commit_reader introduced in go-gitea#13673 whereby commit messages which have a final unterminated line miss their final line. This PR fixes this. Signed-off-by: Andrew Thornton <[email protected]>
There is a slight bug in the commit_reader introduced in #13673 whereby commit messages which have a final unterminated line miss their final line. This PR fixes this. Signed-off-by: Andrew Thornton <[email protected]>
This PR provides alternative git functions to go-git derived functions.
The reasoning is that go-git appears to have a number of significant memory issues and in any case large parts of our git infrastructure use git directly in any case.