On Wed, Aug 14, 2019 at 05:18:44PM +0530, Pratyush Yadav wrote: > > So "git add -p", for example, also works by creating diffs, modifying > > them, and feeding the result to "apply". You can see the implementation > > in git-add--interactive.perl, where it literally calls diff and apply > > commands. > > > > And that leads us to the answer to the first question. That script > > implements "add -p", but also "checkout -p" (which is what you want), > > "reset -p", "stash -p", etc. They differ only in what we diff and how we > > apply the result; the main engine of slicing and dicing the diff through > > user interaction is the same. See the %patch_modes hash for the list. > > Ah, so that means I do have to dive into generating diffs. Too bad, I > was hoping for a cleaner (read: easier) way. > > On that note, I don't suppose there is a way to use > git-add--interactive's diff engine from a script, is there? That'd > allow me to not write potentially buggy code and solve problems someone > already solved. The actual diffing is all done by lower-level commands. So I'm not sure there's much "engine" to reuse from the script. It takes care of asking the user about which lines to look at, how to split the diff, etc, but that's the part you'd want a totally different interface for. The one thing you _might_ want to pick up is the line recounting bits. We used to just call "apply --recount", but I think there were some corner cases that it couldn't handle well. The details are in 2b8ea7f3c7 (add -p: calculate offset delta for edited patches, 2018-03-05) and 3a8522f41f (add -p: don't rely on apply's '--recount' option, 2018-03-05), and probably some mailing list around those. You could probably start with just not handling those corner cases, though (either relying on "apply --recount", or just using whatever git-gui already does now for staging). -Peff
