3 ms·
> 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 l
by 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 agoobject.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> 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. youre making my arguments for me here. youre essentially saying the library is so poorly designed that the "easiest" solution is to create a commit, rather than actually just diffing the worktree directly. > Shell out to `git` and call it a day, or write your own `git` implementation for scratch again, making my arguments for me. youre essentially saying the library is so poor, that is cant support simple use cases and it would be easier to shell out to Git than to write a program that diffs the worktree. > a solution to your use-case. I would say its a solution to essentially every command line user. how many people DONT use git diff? > Clearly you've written to the files in the working directory, otherwise your diff would be blank. the diff it not writing anything. the issue is not "how do I write to a file", that can already be done with the standard library. > If you're writing to working directory files writing to files it done outside the scope of the Git package. the Git package is only needed to handle diffs that were done with some other tool. > your use-case may not be aligned with that of the package authors. git diff?
- 3y ago