3 ms·

> 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 iss

by 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?
  - evanelias 3y ago
    I didn't say that was the "easiest" solution, or ever imply it. Don't put quotes around words I didn't say. That's really not cool. The library is designed for use-cases like getting git metadata or contents from git repos. IIRC, the previous main sponsor (creator?) was a product that let you run SQL SELECT queries against git repos. There's no need to interact with the working tree at all in that type of use-case, so why would they spend a bunch of time implementing diffs for it? If you're trying to use this library for an IDE, or something else like that where arbitrary modifications are made to working dir files, you're going to have a bad time. The library simply wasn't created to do what you want it to do. That doesn't mean it's bad or useless. It's directly imported by Vault, Pulumi, k8s test-infra, etc because its use-case is aligned with what these projects need. Personally I think it's cool that I can use go-git to clone a git repo to memory and then perform programmatic read operations on the repo's contents. That's useful to me. It's not useful to you, and that's fine, but clearly we have different opinions and expectations around community-driven FOSS software projects.

by 38 3y ago

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?
- evanelias 3y ago
  I didn't say that was the "easiest" solution, or ever imply it. Don't put quotes around words I didn't say. That's really not cool. The library is designed for use-cases like getting git metadata or contents from git repos. IIRC, the previous main sponsor (creator?) was a product that let you run SQL SELECT queries against git repos. There's no need to interact with the working tree at all in that type of use-case, so why would they spend a bunch of time implementing diffs for it? If you're trying to use this library for an IDE, or something else like that where arbitrary modifications are made to working dir files, you're going to have a bad time. The library simply wasn't created to do what you want it to do. That doesn't mean it's bad or useless. It's directly imported by Vault, Pulumi, k8s test-infra, etc because its use-case is aligned with what these projects need. Personally I think it's cool that I can use go-git to clone a git repo to memory and then perform programmatic read operations on the repo's contents. That's useful to me. It's not useful to you, and that's fine, but clearly we have different opinions and expectations around community-driven FOSS software projects.