5 ms·

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 d

• 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.
        • evanelias 3y ago
          > no, I am not making a commit just to diff the working directory. OK, you do you. I say it depends on the situation: if this is a throwaway clone (especially an in-memory one), creating a commit is harmless. I mean it's certainly not an ideal solution, but at the end of the day it solves the problem at hand. > would you tell someone to do that with the command line tool as well? It's not my library, I didn't design it, I'm just trying to provide a solution to the problem you posed. If you don't like that solution then, well, OK? Shell out to `git` and call it a day, or write your own `git` implementation for scratch, or send go-git a PR. Any of these would be more productive than complaining about how a free open source library doesn't provide a solution to your use-case. > I am not writing to anything Clearly you've written to the files in the working directory, otherwise your diff would be blank. Again, it's a read-path oriented library. If you're writing to working directory files, your use-case may not be aligned with that of the package authors.
          • 38 3y ago