On Tue, Jul 26, 2011 at 4:55 AM, Jeff King <peff@xxxxxxxx> wrote: > On Sun, Jul 24, 2011 at 12:11:29PM +0700, Nguyen Thai Ngoc Duy wrote: > >> Can we have "git add--interactive --patch --match=regex" where only >> (splitted if possible) hunks that match regex are shown? > > The patch below does this, Thanks! > but there are a lot of unanswered questions. > Such as: > > 1. What does it mean to be "shown"? My patch auto-marks non-matching > hunks as "do not stage". That means you can still switch back to > them in the hunk list and enable them if you want. Another option > would be to omit them entirely, and pretend that those hunks don't > exist. Either way is ok. Maybe the option in this case could be changed to --nostage=regex to reflect the behavior. > 2. What should we do with non-text changes, like mode changes are > full-file deletion? Probably invalid use case for --match. > 3. What should be shown for a file with no matching hunks? Probably > nothing (i.e., as if it had been limited away by pathname)? My > patch shows the header, but that is easy to fix. Printing "Nothing to add" would be nice. > However, I'm not sure I would trust my regex to actually get all of the > changes needed for the refactoring (e.g., there might be nearby hunks > related to the refactoring that are not specifically in the same hunk as > the word "foo"). So I tend to just "git add -p" and flip through the > changes manually. Well, I do "git diff --cached" and "git diff" (the search in the diff) before committing just to make sure I don't miss any changes. > You can already skip around in the hunk list using "/regex". Might that > be enough for you? I think you're stuck typing "/yoursearch" over and > over, though. It would be nice if doing just "/" would search again for > the previous regex. Yes I'm stuck typing /mysearch. Yes, "/" alone would be nice, but in this case I really want mass ignore certain changes so I can focus on important strings first. -- Duy -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html