[prev in list] [next in list] [prev in thread] [next in thread] 

List:       git
Subject:    Re: What's cooking in git.git (Aug 2011, #07; Wed, 24)
From:       Jeff King <peff () peff ! net>
Date:       2011-08-31 2:20:17
Message-ID: 20110831022017.GA3340 () sigill ! intra ! peff ! net
[Download RAW message or body]

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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
[prev in list] [next in list] [prev in thread] [next in thread]