# GSoC git-add--interactive improvements 3 messages from 2012-04-04 to 2012-04-05. Participants: Corey F, Christian Couder. Thread: https://gitlist.dev/t/30143 ## Corey F, 2012-04-04 04:07 Subject: GSoC git-add--interactive improvements Message-ID: <4F7BC8FE.4060808@gmail.com> URL: https://gitlist.dev/e/4F7BC8FE.4060808%40gmail.com ``` Hi all, I'd be interested in making improvements to the git add -p (etc.) interface as a Google Summer of Code project, as suggested on the ideas page [1]. The page lists some interesting ideas for both larger architectural changes and smaller interface improvements, though I agree that getting lots of community input during the project will be important. So at this point I'm wondering how much I should plan out in my proposal -- maybe pin down a few important features and a process for getting more input? Last year's SoC ideas page included rewriting some commands in C, including this one. I'm at least as comfortable with C as with Perl, but I'm guessing that incorporating a rewrite into the project would be an ambitious and/or dangerous idea. Any thoughts on how best to approach this project idea are welcome. Alternately, the "ultimate content tracking" tool to find similar sections that might have been the basis for newly added lines sounds intriguing, and I will refresh myself on the previous list discussion regarding that idea. Thanks, Corey 1: https://github.com/peff/git/wiki/SoC-2012-Ideas ``` ## Christian Couder, 2012-04-04 08:26 Subject: Re: GSoC git-add--interactive improvements Message-ID: URL: https://gitlist.dev/e/CAP8UFD0V17Gag3esFd%3DZDocZZoiN_4a1bjQ8rFwbBZoJEiasBA%40mail.gmail.com In-Reply-To: <4F7BC8FE.4060808@gmail.com> ``` Hi, On Wed, Apr 4, 2012 at 6:07 AM, Corey F wrote: > Hi all, > > I'd be interested in making improvements to the git add -p (etc.) interface > as a Google Summer of Code project, as suggested on the ideas page [1]. > > The page lists some interesting ideas for both larger architectural changes > and smaller interface improvements, though I agree that getting lots of > community input during the project will be important. So at this point I'm > wondering how much I should plan out in my proposal -- maybe pin down a few > important features and a process for getting more input? > > Last year's SoC ideas page included rewriting some commands in C, including > this one. I'm at least as comfortable with C as with Perl, but I'm guessing > that incorporating a rewrite into the project would be an ambitious and/or > dangerous idea. It depends how you plan to do it. In builtin/apply.c and perhaps elsewhere there is already some C code that is duplicated in git-add--interactive.perl. Maybe you can first make add--interactive use the C code by creating a helper command and then move more and more stuff from add--interactive to the helper command. Hopefully in the end the code in the helper could be used to add an interactive mode to git apply. Thanks, Christian. PS: Sorry I replied to you only first. ``` ## Corey F, 2012-04-05 05:46 Subject: Re: GSoC git-add--interactive improvements Message-ID: <4F7D3199.5040401@gmail.com> URL: https://gitlist.dev/e/4F7D3199.5040401%40gmail.com In-Reply-To: ``` On 04/04/2012 01:26 AM, Christian Couder wrote: > Hi, > > On Wed, Apr 4, 2012 at 6:07 AM, Corey F wrote: >> Last year's SoC ideas page included rewriting some commands in C, including >> this one. I'm at least as comfortable with C as with Perl, but I'm guessing >> that incorporating a rewrite into the project would be an ambitious and/or >> dangerous idea. > It depends how you plan to do it. In builtin/apply.c and perhaps > elsewhere there is already some C code that is duplicated in > git-add--interactive.perl. > Maybe you can first make add--interactive use the C code by creating a > helper command and then move more and more stuff from add--interactive > to the helper command. > Hopefully in the end the code in the helper could be used to add an > interactive mode to git apply. Okay, that sounds like an interesting way to approach it. The helper command would then constitute a slightly more generic patch-chooser interface, and most of the suggested architectural changes would be broadly applicable. Then again, perhaps it would be better to instead, as a sub-project, make git-add--interactive.perl work for apply in addition to add,commit,stash,reset. That would let me still primarily focus on restructuring the Perl code. I think the first few suggested design improvements, in particular, will be valuable changes. (I often find myself wanting even more granular control over what exact characters get staged; that may be another improvement I'll aim for.) I'll think about these some more and hope to put together a GSoC application. Thanks for your insights. Corey ```