On Tue, Jul 26, 2011 at 12:57:46PM +0700, Nguyen Thai Ngoc Duy wrote: > It's my itch. I'm more than happy if you take care of the Perl part, > I'll do the rest. While you're doing the Perl part, should we have > both --match and --no-match? One filters in. The other filters out. I > guess people may find filter-in case more helpful than the other. Yeah. Also, what about grep options like case-insensitivity? I don't want to go too overboard with adding options that are unlikely to be used. It is perl, so technically you can do "(?i:foo)" to match "foo" case-insensitively. I don't think there's a way to do --no-match style negation in the regex itself, though. Speaking of which: the name "--match" is way too generic for "git add". Something like "--hunk-match" would be better. It also is obviously only useful with "--patch". Should it imply "--patch"? Should it actually be "--patch=..."? > I thought of this way initially, but I needed to split hunks in > parse_diff and was stuck because I was not familiar with data > structure used in git-add--interactive. Oh yeah, you mentioned splitting before. I'm not sure how that would interact with this feature. In some cases, you'd want to split as much as possible, and in other cases, you'd want a bigger hunk. So I actually think it is an orthogonal feature to "autosplit" hunks before we show them to the user. I.e., something like: git add -p --autosplit-hunks --hunk-match=... (where maybe the names could be better, but hopefully you get the point). -Peff -- 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