6 ms·

I have been wanting something like this, but with a few more features such as "git diff". I took a crack at it, but the popular (and maybe only) Go Git implemen

by 38 3y ago

I have been wanting something like this, but with a few more features such as "git diff". I took a crack at it, but the popular (and maybe only) Go Git implementation has some issues: https://github.com/go-git/go-git/issues/700 https://github.com/go-git/go-git/issues/700

anacrolix 3y ago
Are you 1268? Are you creating identities on platforms by bruteforcing the lowest available cardinal? Because that is a great idea
- 38 3y ago
  yes and yes :)
  - pravus 3y ago
    I love this and will make sure to support this kind of thing in a login system I am building.
evanelias 3y ago
In my opinion github.com/go-git/go-git is a very high-quality project. Just because it doesn't solve some super-specific use-case that you have, doesn't mean the project isn't good. It's open source, have you tried opening a pull request to solve your own issue?
- xyzzy_plugh 3y ago
  In truth it's a bit of a tire fire. You're better off shelling out to git in almost all cases. I tried using it to automate some simple git workflows and found pitfalls everywhere.
  - evanelias 3y ago
    Sorry to hear that, but go-git is good enough to be useful to Vault, Pulumi, kubernetes/test-infra, and many other projects which directly import it. Some folks seem to expect it to be a feature-complete library-usable Go re-implementation of the entirety of Git, despite it being (afaik) largely unfunded / volunteer-driven in recent years. I don't think that's realistic. And yes in many use-cases it may indeed make more sense to shell out to `git`, there's nothing wrong with that. In any case, in my direct experience, the go-git maintainers do happily accept helpful PRs. It just seems really weird to me to see folks trash go-git, while simultaneously cheering this new gogit project which is just 400 lines and intentionally by design/scope contains only a tiny fraction of go-git's functionality.
    - xyzzy_plugh 3y ago
      > go-git aims to be fully compatible with git, all the porcelain operations are implemented to work exactly as git does. It literally says this on the tin, yes. But it's not. I'm simply providing my own experience and a disclaimer. Sure, they "happily accept helpful PRs" but the code is so very complex and many paths have horrible performance that it's an incredible uphill battle. To be clear I'm not simply shitting on this library, I'm saying it's not a reasonable choice over just using git directly, and is unlikely to ever be. I haven't made any comment on TFA so while I'm not cheering it on, I do think the spirit is correct: just do the thing you need to do, don't try to be feature complete, just solve the task at hand.
      - evanelias 3y ago
        I interpret "aims to be fully compatible" as meaning the operations it implements are intended to be compatible with how Git implements those operations. I do not interpret this statement as saying they implement all features of Git. They offer a document which directly shows what is and isn't supported, and it specifically notes quite a few things that aren't supported yet: https://github.com/go-git/go-git/blob/master/COMPATIBILITY.md https://github.com/go-git/go-git/blob/master/COMPATIBILITY.m... The godoc also says right upfront it "nowadays covers the majority of the plumbing read operations and some of the main write operations, but lacks the main porcelain operations such as merges." - https://pkg.go.dev/github.com/go-git/go-git/v5#pkg-overview https://pkg.go.dev/github.com/go-git/go-git/v5#pkg-overview > I'm saying it's not a reasonable choice over just using git directly, and is unlikely to ever be. OK, that's apparently true for your use-case. But again, what go-git implements is directly useful to a number of very popular projects, as well as literally two thousand less popular ones. I find the exported functionality to be high quality, at least for my own use-case. I'm not commenting on the code quality. If I need a shed for bikes, and someone is giving out free but ugly bikesheds, I'm thankful. I don't complain about the color of the bikeshed.
- 38 3y ago
  not really. its littered with interfaces, in some cases many levels deep, which in Go is an anti pattern. original author clearly came from Java or some other deeply OOP language. also: > super-specific use-case uh, "git diff" is specific?
  - evanelias 3y ago
    If I understand your issue correctly, it's `git diff --cached` that you're specifically looking for, not just `git diff` in general? Your expectation seems to be that someone has already implemented this in Go for you, for free, but this is not the case. Why is this your expectation, and what does complaining about it accomplish?
    - 38 3y ago
      > If I understand your issue correctly, it's `git diff --cached` that you're specifically looking for, not just `git diff` in general? incorrect. I am simply looking for a normal "git diff", which compares the index with the working directory. shocking this is not available out of the box, hence my issue.
      - evanelias 3y ago
        object.Tree has a Diff() method. You can get an object.Tree of any commit hash from a Repository with its TreeObject() method. I don't recall offhand how to get an object.Tree of the working directory or index (perhaps from the Repository.Storer?) but worst-case you could just create a new commit in order to get a hash and then run the diff. The package is more read-oriented than write-oriented; the docs specifically say it "covers the majority of the plumbing read operations and some of the main write operations". If you're trying to diff working directory modifications, that's a write-path use-case since it implies files are being changed / you're not trying to diff two pre-existing commits. (edit: removed some text based on an initial misreading of your statement.)
        38 3y ago
        > You can get an object.Tree of any commit hash from a Repository with its TreeObject() method. OK, but I am not dealing with a commit, as mentioned in the issue and my previous comment, I am dealing with THE INDEX and working directory, not a commit. > I don't recall offhand how to get an object.Tree of the working directory or index (perhaps from the Repository.Storer?) right, so you can see how its not as easy to hand wave away the problem as you initially thought. > worst-case you could just create a new commit in order to get a hash and then run the diff. no, I am not making a commit just to diff the working directory. would you tell someone to do that with the command line tool as well? > The package is more read-oriented than write-oriented; the docs specifically say it "covers the majority of the plumbing read operations and some of the main write operations". cool, we are talking about a read operation, no writing is being done. > If you're trying to diff working directory modifications, that's a write-path use-case since it implies files are being changed / you're not trying to diff two pre-existing commits. no its not. I am not writing to anything, only reading.

by 38 3y ago

anacrolix 3y ago

Are you 1268? Are you creating identities on platforms by bruteforcing the lowest available cardinal? Because that is a great idea

38 3y ago
yes and yes :)
- pravus 3y ago
  I love this and will make sure to support this kind of thing in a login system I am building.

evanelias 3y ago

In my opinion github.com/go-git/go-git is a very high-quality project. Just because it doesn't solve some super-specific use-case that you have, doesn't mean the project isn't good. It's open source, have you tried opening a pull request to solve your own issue?

xyzzy_plugh 3y ago
In truth it's a bit of a tire fire. You're better off shelling out to git in almost all cases. I tried using it to automate some simple git workflows and found pitfalls everywhere.
- evanelias 3y ago
  Sorry to hear that, but go-git is good enough to be useful to Vault, Pulumi, kubernetes/test-infra, and many other projects which directly import it. Some folks seem to expect it to be a feature-complete library-usable Go re-implementation of the entirety of Git, despite it being (afaik) largely unfunded / volunteer-driven in recent years. I don't think that's realistic. And yes in many use-cases it may indeed make more sense to shell out to `git`, there's nothing wrong with that. In any case, in my direct experience, the go-git maintainers do happily accept helpful PRs. It just seems really weird to me to see folks trash go-git, while simultaneously cheering this new gogit project which is just 400 lines and intentionally by design/scope contains only a tiny fraction of go-git's functionality.
  - xyzzy_plugh 3y ago
    > go-git aims to be fully compatible with git, all the porcelain operations are implemented to work exactly as git does. It literally says this on the tin, yes. But it's not. I'm simply providing my own experience and a disclaimer. Sure, they "happily accept helpful PRs" but the code is so very complex and many paths have horrible performance that it's an incredible uphill battle. To be clear I'm not simply shitting on this library, I'm saying it's not a reasonable choice over just using git directly, and is unlikely to ever be. I haven't made any comment on TFA so while I'm not cheering it on, I do think the spirit is correct: just do the thing you need to do, don't try to be feature complete, just solve the task at hand.
    - evanelias 3y ago
      I interpret "aims to be fully compatible" as meaning the operations it implements are intended to be compatible with how Git implements those operations. I do not interpret this statement as saying they implement all features of Git. They offer a document which directly shows what is and isn't supported, and it specifically notes quite a few things that aren't supported yet: https://github.com/go-git/go-git/blob/master/COMPATIBILITY.md https://github.com/go-git/go-git/blob/master/COMPATIBILITY.m... The godoc also says right upfront it "nowadays covers the majority of the plumbing read operations and some of the main write operations, but lacks the main porcelain operations such as merges." - https://pkg.go.dev/github.com/go-git/go-git/v5#pkg-overview https://pkg.go.dev/github.com/go-git/go-git/v5#pkg-overview > I'm saying it's not a reasonable choice over just using git directly, and is unlikely to ever be. OK, that's apparently true for your use-case. But again, what go-git implements is directly useful to a number of very popular projects, as well as literally two thousand less popular ones. I find the exported functionality to be high quality, at least for my own use-case. I'm not commenting on the code quality. If I need a shed for bikes, and someone is giving out free but ugly bikesheds, I'm thankful. I don't complain about the color of the bikeshed.
38 3y ago
not really. its littered with interfaces, in some cases many levels deep, which in Go is an anti pattern. original author clearly came from Java or some other deeply OOP language. also: > super-specific use-case uh, "git diff" is specific?
- evanelias 3y ago
  If I understand your issue correctly, it's `git diff --cached` that you're specifically looking for, not just `git diff` in general? Your expectation seems to be that someone has already implemented this in Go for you, for free, but this is not the case. Why is this your expectation, and what does complaining about it accomplish?
  - 38 3y ago
    > If I understand your issue correctly, it's `git diff --cached` that you're specifically looking for, not just `git diff` in general? incorrect. I am simply looking for a normal "git diff", which compares the index with the working directory. shocking this is not available out of the box, hence my issue.
    - evanelias 3y ago
      object.Tree has a Diff() method. You can get an object.Tree of any commit hash from a Repository with its TreeObject() method. I don't recall offhand how to get an object.Tree of the working directory or index (perhaps from the Repository.Storer?) but worst-case you could just create a new commit in order to get a hash and then run the diff. The package is more read-oriented than write-oriented; the docs specifically say it "covers the majority of the plumbing read operations and some of the main write operations". If you're trying to diff working directory modifications, that's a write-path use-case since it implies files are being changed / you're not trying to diff two pre-existing commits. (edit: removed some text based on an initial misreading of your statement.)
      - 38 3y ago
        > You can get an object.Tree of any commit hash from a Repository with its TreeObject() method. OK, but I am not dealing with a commit, as mentioned in the issue and my previous comment, I am dealing with THE INDEX and working directory, not a commit. > I don't recall offhand how to get an object.Tree of the working directory or index (perhaps from the Repository.Storer?) right, so you can see how its not as easy to hand wave away the problem as you initially thought. > worst-case you could just create a new commit in order to get a hash and then run the diff. no, I am not making a commit just to diff the working directory. would you tell someone to do that with the command line tool as well? > The package is more read-oriented than write-oriented; the docs specifically say it "covers the majority of the plumbing read operations and some of the main write operations". cool, we are talking about a read operation, no writing is being done. > If you're trying to diff working directory modifications, that's a write-path use-case since it implies files are being changed / you're not trying to diff two pre-existing commits. no its not. I am not writing to anything, only reading.