Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [egit-dev] Google Summer of Code (GSOC) Participation

Dariusz Luksza <dariusz.luksza@xxxxxxxxx> wrote:
> After some investigations I've choose 3 features (order in list
> is important):
>
> 1. UI for tagging - this is rather trivial task, but IMHO it good
>    to start playing EGit/JGit sources

Indeed, its a good quick start.  But to do signed tags, its going
to be messy fast.  We briefly looked into things, and we can't
import Bouncy Castle Crypto to implement the PGP signature.  I'm not
happy about the idea of forking out to GnuPG on the command line.
But it might be the only option we can get through the IP process.

So this is only a trivial task if you are talking about lighweight
and unsigned annotated tags.  Which is a good start and still useful
to some folks.

> 2. rename detection - it is rather intermediate level. Right now
>    JGit (and also EGit) has support for branch renaming and as  I
>    see it, it can be also used for file rename/move detection

You are confusing two different concepts.  Branch renaming has
nothing to do with rename/move detection.  Nothing at all.

Rename detection is actually harder than it sounds.  We need a
difference algorithm we can run on *binary* files, not just the
text algorithm we currently run.

You probably can reuse MyersDiff, but the Sequence needs to be
broken down at some sort of block boundary rather than line, and
IIRC C Git's binary difference here permits those blocks to slide,
so that an insertion/deletion of a non-block-sized segment doesn't
trigger the whole thing to be different.

The naive rename detection is O(A*D), where A is the number of files
that were added and D is the number of files that were deleted.
Which is basically O(N^2) if N is the number of files that we
care about.  In practice this matrix can get big fast, and C Git
has played some tricks to try and cut down on the dimensions and
number of compares it does.

A naive rename detection is a great start, and is way better than
what we have now.  But doing this well is easily a GSoC project in
my opinion.

> 3. add core and UI support for stashing - this feature should be
>    implemented almost from scratch because JGit does not contains
>    support for stash.

Yes.  This along with some other stuff might also be a full GSoC
project, where "other stuff" doesn't include rename detection.

I think you have some great ideas.  Just doing 2 and 3 is going to
be biting off a lot.  You should decide which you want to work on,
rename detection, or UI features that are going to immediately
benefit common users.

-- 
Shawn.


Back to the top