3 ms·

> 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

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

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.