git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Marek Zawirski <marek.zawirski@gmail.com>
To: git@vger.kernel.org, gsoc@spearce.org
Subject: [SoC] egit: pre-proposal, problem recognition
Date: Sat, 22 Mar 2008 17:25:01 +0100	[thread overview]
Message-ID: <47E532DD.7030901@gmail.com> (raw)

Hello Git Team,

I'm a student interested participating in egit/jgit project for this 
year GSoC. Here I'm trying to investigate what can and need to be done 
for egit plugin and jgit library -> I'm asking you kindly for some 
comments or answers. That's somehow pre-proposal, as I'd like to know on 
which part should I do more research before preparing more detailed 
proposal.

[my git-awareness status]
To this time, I've used mainly SVN as version control. Last days were my 
first days with git, and I'm excited :) I've been doing some intensive 
learning: now I feel quite confident as a git user, also have done 
overview of git's internals (.git/ structure, data structures: DAG of 
objects, branches, tags, index etc.) and workflow of main operations. 
I've also downloaded and tested egit plugin on my Eclipse instance, and 
looked over jgit and egit code (nice!).
[/my git-awareness status]

Let's start from some clean-up:
http://git.or.cz/gitwiki/EclipsePluginWishlist - isn't this site a 
little outdated? It appears that tasks: Commit, Switch Branch (without 
dirty workspace/merge support) are already done, aren't they?
Some operations look for me as rather straight-forward to implement - 
not appropriate for a whole GSoC project (or do I underestimate?). 
Namely: Create/Delete Branch, Create/Delete Tag, Gitignore, Checkout(?).
GSoC2008 site states, that most wanted tasks are (that's reasonable) 
Push and Merge implementation. Fetch operation also looks to be not 
implemented yet? Do you agree that is also one of most important 
operation not yet supported? It seems that Pull and Clone are tasks for 
future, because of Merge or Fetch dependencies.

So what can I do:
I think that 1-2 from 3 main jgit+egit tasks (Push, Fetch, Merge) appear 
to be well-sized for a GSoC project. IMO, there is also need for a lot 
of smaller improvements in egit itself: preferences, preference page, 
user-friendliness related: more icons and information, help in dialogs, 
wizards, menus etc. I'm thinking of taking 1 main task - implementing 
first jgit part, then egit part. And if I finish it before time, I could 
work on set of such smaller improvements in egit itself, to make it 
easier/nicer for user.
I'm particulary interested in protocol implementation (Fetch or Push 
operation) as main-task, but Merge also looks interesting. What is more, 
I perceive Merge and Fetch operations as most wanted, because being on 
project critical-path, blocking implementation of other tasks. Merge 
seems also to be used very often itself.

Current implementation status:
There is currently no Eclipse (GUI, workspace logic) code directly for 
each of main tasks.
What about jgit? I haven't looked at details of implementation yet 
(sorry, I'm starting), but...
For Fetch or Push: I'll need to implement protocol(s) for sure: git, ssh 
protocols first as wiki-recommends - wisely, I think. What about support 
from jgit internals: do I need to add some git structures implementation 
to accomplish Fetch or Push: like object packing, needed objects 
tracking? Or is almost everything available, so I just need to use this 
structures and concentrate on upload/receive operation and protocol 
implementation? In case of Fetch, I guess that Create Branch (easy?) 
implementation is also needed. Is local Fetch or Push already supported 
in jgit? If not, I'd start from this. I've got also some doubts 
concerning SSH vs git access protocols. Are git-receive-pack and 
git-upload-pack used by both of these access protocols? If so, it make 
things easier:)
For Merge: I'll need to implement 3-way merge algorithm. Wiki says that 
one can look at Eclipse, if it is already implemented there. IMHO it's 
better to implement it at jgit level, independently of egit, basing on 
original git implementation, don't you think (I've seen that there are 
some efforts to implement git plugin for NetMeans, basing on jgit 
library)? I wonder how laborious this task is, i.e. as for Fetch/Push: 
does translation of this algorithm written in C to Java requires 
significant changes or improvements to existing jgit code?

What do you think about importance of each task and what is your feeling 
about time needed to implement each?


At the end, few words about me, what you could expect:
I'm a BSc/MSc undergraduate of a Computer Science course at Poznan 
University of Technology (Poland). My main areas of interests are 
distributed systems and software engineering, especially quality of 
software. I'm quite experienced Java developer; and C is my "second" 
language, so I can analyze existing git implementation. I've finished 
Eclipse Summer School workshop some time ago - on Eclipse plugins 
development, so I've got some knowledge on Eclipse internals. I'm ready 
to implement protocol or algorithm when needed.
I've got some experiences with JSch (bad experience...) and Trilead SSH 
(much more postive) - BSD-licensed SSH implementations for Java.

To this time I was working on many smaller projects, and one bigger (>1 
year, BSc and grids related), mostly in small teams, sometimes 
distributed. It seems to be great experience if I can join git community:)

Thank you for your attention, I'd appreciate any comments, expectations 
or info (answers)! If you want I can move to private discussion.

PS BTW: I've wonder what "Checkpoint project" in Eclipse Team menu 
stands for?

-- 
Marek Zawirski [zawir]
marek.zawirski@gmail.com

             reply	other threads:[~2008-03-22 16:25 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-22 16:25 Marek Zawirski [this message]
2008-03-23  7:52 ` [SoC] egit: pre-proposal, problem recognition Shawn O. Pearce
2008-03-23 22:44   ` Robin Rosenberg
2008-03-25 16:29     ` Marek Zawirski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=47E532DD.7030901@gmail.com \
    --to=marek.zawirski@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gsoc@spearce.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).