Re: What's cooking in git.git (Aug 2011, #07; Wed, 24)

From: Jeff King <peff@peff.net>
Date: Aug 31, 2011, 02:20 UTC
Message-ID: <20110831022017.GA3340@sigill.intra.peff.net>
In-Reply-To: <7vhb55i11i.fsf@alter.siamese.dyndns.org>

On Thu, Aug 25, 2011 at 03:22:49PM -0700, Junio C Hamano wrote:

Show 20 quoted lines

> > 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.

Show 10 quoted lines

> >> 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