Dne úterý 05 dubna 2011 18:52:12 Jeff King napsal(a):
> On Mon, Apr 04, 2011 at 09:43:09AM +0200, Robert David wrote:
> > Today git code consists of the base written in C and many helper shell or
> > PERL scripts. While at a first time it is easier to write the script,
> > final code is supposed to be in C. One of these scripts is
> > git-add--interactive.
> > 
> > Git-add--interactive is a helper script for git-add, which servers its
> > options -i and -p. It definitely need to be integrated in git-add.
> 
> Can you expand on "definitely" here? I.e., what are the motivations for
> this change? I know what some of the arguments are, and I know how _I_
> would answer the question, but I want to hear what _you_ think.


From my point of view it means to keep the code consistent in the whole 
project. This further means better porting, avoid duplications and thus easier 
maintenance. And at last, I think it is my personality that takes me to 
project like this. I like to polish things up. 

Even I like the PERL, I would not like to maintain project consisted in more 
programming languages for a long term.


> 
> And I am not just trying to be pedantic. Understanding the motivations
> for a change will help us figure out the right way to go about it, and
> how to figure out if we are successful at making it.
> 
> > Interfaces
> > As this is mainly part of git-add, that means that it will need to be
> > changed at the most.
> > There are also another commands using this functionality now: git-am,
> > git- checkout, git-rebase.
> 
> I don't think this is right. "am" and "rebase" have interactive modes,
> but the code and functionality are not shared at all with
> add--interactive. But you are missing some other commands that do have
> patch modes built on add--interactive.

Thanks for the notice, I will dive more deeply into it.


I was also thinking about the timeline of this project. And maybe another 
solution is to constantly and slowly improve git-add--interactive, to make it 
accepted in next (maybe master) on end of the SoC period. And in parallel 
write the C code, which would be prepared for more longer term testing and 
bugfixing to get in next. This also means for me a clear way, how to continue 
contributing to git.

Robert 

> 
> -Peff