Proposal for GSoC, want to get your opinions
apaku at gmx.de
Tue Feb 26 12:15:30 UTC 2008
On 26.02.08 11:05:32, David Nolden wrote:
> On Tuesday 26 February 2008 07:50:35 Andreas Pakulat wrote:
> > Depending on the students pre-knowledge I think yes. Its not just about
> > writing a parser for the git output and calling git from inside
> > KDevelop.
> Btw. please do NOT write an own parser if not absolutely needed, we have
> already have to maintain enough of them in kdevelop-4, and I've seen it take
> a lot of time.
For a full blown language like Python, sure. But for the output of some
commandline tool its not that much of a problem, IMHO. At least as far
as I can see the amount of parsing done in CVS support is really little
(it even gets away with QRegex).
> It would be best if the cores of already available and stable
> applications like qgit and gitk could be re-used.
That essentially means forking them, having to understand that code...
Depending on the existing knowledge of whoever does this it might be
faster than to write a parser, or it might slow down even more...
> A problem about git is that the interface will probably change yet, so being
> code-wise close to those apps would make accomodating to such changes easy.
Interface? Which interface? There is none. I don't think any of us
seriously considers commandline output an interface.
Using the ouput is a hack, no matter what. However I don't see us fixing
the underlying architectural problem in git (or feature, whatever you
want to call it).
Anyway, if we can borrow the parsing code and other parts from qgit (I
don't see much value doing that with gitk) then yes, it might help to
start off fast. I'm not so sure about long-term maintenance, that might
proove to be hard as I suspect we'll going to adapt the forked sources
or fix bugs ourselves...
So my conclusion is: Wait and see wether the project is accepted and
what the student thinks gets him further...
Good night to spend with family, but avoid arguments with your mate's
More information about the KDevelop-devel