What do you think about https://github.com/src-d/go-git , i use it for some git operations like pull, clone and other and it works fine. As i know gogs work with git via adaptor package, so i can try to create replacement for git operations in pure go. Does this acceptable or not ?
Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.
If it can entirely replace the git cli and doesn't depend on cgo I'm fine with that
take care about the performance ;)
Why go-git instead of https://github.com/libgit2/git2go ? Imo libgit2 is really good
Because it requires cgo and libgit.
The first version of Gogs is based https://github.com/gogits/git. We have tried to use pure Go. But it developments slowly and run slower than git command. If the https://github.com/src-d/go-git is full-featured and almost the same performance with git command, I prefer that.
It would be worth using an interface for git operations and support either pure-go implementation or libgit2, with a build tag. The sqlite backend is also cgit so I don't see why not allowing it in codebase...
Great idea, we indeed need an interface on go-gitea/gitea
and let go-gitea/git
become as the default implementation.
@lunny I'd rather put the interface in go-gitea/git
and have the build-tag there TBH, otherwise we'd end up in a state where we need an interface in gitea
, a wrapper for go-git
and a wrapper for gitea/git
@bkcsoft How about mixed the two methods since https://github.com/src-d/go-git maybe not full-feature?
Hence the proposal for having both in the same repo (go-gitea/git
), that way we can have commit_exec.go
and commit_pure.go
where we can, and only repo_merge_exec.go
where src-d/go-git
isn't usable 馃檪
+1 for doing this in go-gitea/git
Continued from #1511
@strk
If I read correctly the code in its current version does not support merges ?
Yes.
See https://github.com/src-d/go-git
Also, are you suggesting to use this as one of the implementations of the go-gitea/git interface as proposed somewhere else or as the primary API for git work ?
My proposal was to use it as the primary API replacing go-gitea/git/
The approach using go-gitea/git as the interface is okay to me. But such abstraction can be eliminated in the long term.
Did you test performance compared to libgit ?
No. I assume it would have good, if not better, performance than other alternatives if the cgo overhead doesn't matter that much. But cgo does affect the developer experience to some extent.
A performance compare on a git sub command is welcome. For example, get releases page is too slow, if we use this library will retrieve better performance, it's great!
It should be fairly simple to test performance gains like this:
Just a heads-up: I actually made some effort in this direction, it is discussed in issue #491 along with links to my code and some performance numbers.
If I was to work on integrating gitea with https://github.com/src-d/go-git, where do I start?
@pjebs I think you could send PRs to https://github.com/go-gitea/git to instead git commands to pure go library. I think it's easier to do it step by step.
@pjebs Incrementally implementing the exported APIs of https://github.com/go-gitea/git seems to be a good idea.
@pjebs Follow the suggestion by @typeless and @lunny. I already have a branch where I started doing that, so if you split the git
module changes and gitea
changes and help upstream it I'd be more than grateful. https://github.com/filipnavara/gitea/tree/perf-read
Give me some time to understand the code base since I only found the repo a few days ago.
Then I'll look at starting the process.
@pjebs I think there are some part has used https://github.com/src-d/go-git and @filipnavara contributed a lot. You can go to modules/git
to find them.
since we use both (go-git and a git warper) and it doesn't look like go-git can take up for all git tasks I'll close this for now.
It can be reconsidered in the future if things change ...
Most helpful comment
If it can entirely replace the git cli and doesn't depend on cgo I'm fine with that