On Thu, Aug 25, 2011 at 03:22:49PM -0700, Junio C Hamano wrote: > > On Wed, Aug 24, 2011 at 05:09:09PM -0700, Junio C Hamano wrote: > > > >> * jk/add-i-hunk-filter (2011-07-27) 5 commits > >> (merged to 'next' on 2011-08-11 at 8ff9a56) > >> + add--interactive: add option to autosplit hunks > >> + add--interactive: allow negatation of hunk filters > >> + add--interactive: allow hunk filtering on command line > >> + add--interactive: factor out regex error handling > >> + add--interactive: refactor patch mode argument processing > >> > >> Needs documentation updates. > > > > I think Duy already mentioned this, but you may want to update your > > "what's cooking" note: it needs not just doc updates, but code to > > actually pass the options along from real git commands that use > > add--interactive, like add, checkout, reset, and stash. > > Thanks. Also tests are lacking, too. Although I do not necessarily see the > lack of integration with anything but "add" a show-stopper (I consider > "-p" to chekout, reset and stash are "nice to have"), [...] It is less ready than that. You cannot even use it from "git add" at this point. It is _only_ the perl bits, as I was just providing them to Duy, so he could write the C bits. So the patches as they are are useless. Hence no tests, since you can't even trigger the code without artifically calling add--interactive directly with the new options. So it probably makes sense to just drop them (or just leave them in pu) for the next cycle until the other half materializes. > you are correct that "add -i" and then choosing '[p]atch' gets very > confused with Hmm, that is a regression probably caused by my refactoring. Thanks for pointing it out. I'll take a look. > >> The initial "tag --contains" de-pessimization without need for generation > >> numbers is already in; backburnered. > > > > So...what next? I don't really like leaving the contains traversal > > as-is. > > Hmm, honestly speaking, I do not see much problem with it. My knee-jerk > reaction is to go with 1.a and if we really want to do something 1.b > perhaps but I suspect "these are bogus" cache wouldn't be so useful by > itself and we may need a bit more information. OK. I'll clean up and submit a patch for that, but I'll wait for post-1.7.7. -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