On Fri, Dec 13, 2024 at 10:41:25AM -0600, Justin Tobler wrote: > > The patch might look something like this: > > > > https://lore.kernel.org/git/20161201204042.6yslbyrg7l6ghhww@xxxxxxxxxxxxxxxxxxxxx/ > > > > :) That is what has been powering the diffs at github.com since 2016 or > > so. And continues to do so, as far as I know. I don't have access to > > their internal repository anymore, but I've continued to rebase the > > topic forward in my personal repo. You can fetch it from: > > > > https://github.com/peff/git jk/diff-pairs > > > > in case that is helpful. > > Thanks Peff! From looking at the mentioned thread and branch, it looks > like I'm basically trying to accomplish the same thing here. Just a bit > late to the conversation. :) > > While the use-case is rather narrow, I think it would be nice to see > this functionality provided upstream. I see this as a means to faciliate > more fine-grained control of the blob diffs we actually want to compute > at a given time and it seems like it would be reasonable to expose as > part of the diff plumbing. I would certainly be interested in adapting > this series to instead use raw input from git-diff-tree(1) or trying to > revive the previous series if that is preferred. Yeah, if you want to take it in that direction, either by adapting the idea, or by starting with diff-pairs and polishing it up, I'm happy either way. GitHub folks may be happy if you keep the name "diff-pairs" and match the interface. ;) > If there is interest in continuing, some lingering questions I have: > > Being that the primary purpose of git-diff-blob(1) here is to handle > generating blob diffs as specified by stdin, is there any reason to have > a normal mode that accepts a blob pair as arguments? Or would it be best > to limit the input mechanism to stdin entirely? If the user wanted to > compute a single blob diff they could just use git-diff(1) already so > providing this as a part of git-diff-blob(1) is a bit redundant. Having > it as an option for the user does seem a bit more friendly though. I don't have a strong opinion. I agree it _could_ be more friendly, but it also raises questions about how that mode/path context is filled in. And also about other modes. E.g., "git diff HEAD:foo bar" will diff between a blob and a working tree. Should a new plumbing command support that, too? If those aren't things you immediately care about, I'd probably punt on it for now. I think it could be added later without losing compatibility (command-line arguments as appropriate for a single pair, and since the stdin format starts with ":mode" there's room to extend it). -Peff
