{"thread":{"id":"12810","subject":"[SoC] egit: pre-proposal, problem recognition","startedAt":"2008-03-22T16:25:01Z","lastAt":"2008-03-25T16:29:41Z","messageCount":4,"participants":["Marek Zawirski","Shawn O. Pearce","Robin Rosenberg"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"72674","messageId":"47E532DD.7030901@gmail.com","threadId":"12810","inReplyTo":null,"subject":"[SoC] egit: pre-proposal, problem recognition","fromName":"Marek Zawirski","fromEmail":"marek.zawirski@gmail.com","sentAt":"2008-03-22T16:25:01Z","receivedAt":"2008-03-22T16:25:01Z","isPatch":false,"sender":{"key":"marek.zawirski@gmail.com","avatar":null},"body":"Hello Git Team,\n\nI'm a student interested participating in egit/jgit project for this \nyear GSoC. Here I'm trying to investigate what can and need to be done \nfor egit plugin and jgit library -> I'm asking you kindly for some \ncomments or answers. That's somehow pre-proposal, as I'd like to know on \nwhich part should I do more research before preparing more detailed \nproposal.\n\n[my git-awareness status]\nTo this time, I've used mainly SVN as version control. Last days were my \nfirst days with git, and I'm excited :) I've been doing some intensive \nlearning: now I feel quite confident as a git user, also have done \noverview of git's internals (.git/ structure, data structures: DAG of \nobjects, branches, tags, index etc.) and workflow of main operations. \nI've also downloaded and tested egit plugin on my Eclipse instance, and \nlooked over jgit and egit code (nice!).\n[/my git-awareness status]\n\nLet's start from some clean-up:\nhttp://git.or.cz/gitwiki/EclipsePluginWishlist - isn't this site a \nlittle outdated? It appears that tasks: Commit, Switch Branch (without \ndirty workspace/merge support) are already done, aren't they?\nSome operations look for me as rather straight-forward to implement - \nnot appropriate for a whole GSoC project (or do I underestimate?). \nNamely: Create/Delete Branch, Create/Delete Tag, Gitignore, Checkout(?).\nGSoC2008 site states, that most wanted tasks are (that's reasonable) \nPush and Merge implementation. Fetch operation also looks to be not \nimplemented yet? Do you agree that is also one of most important \noperation not yet supported? It seems that Pull and Clone are tasks for \nfuture, because of Merge or Fetch dependencies.\n\nSo what can I do:\nI think that 1-2 from 3 main jgit+egit tasks (Push, Fetch, Merge) appear \nto be well-sized for a GSoC project. IMO, there is also need for a lot \nof smaller improvements in egit itself: preferences, preference page, \nuser-friendliness related: more icons and information, help in dialogs, \nwizards, menus etc. I'm thinking of taking 1 main task - implementing \nfirst jgit part, then egit part. And if I finish it before time, I could \nwork on set of such smaller improvements in egit itself, to make it \neasier/nicer for user.\nI'm particulary interested in protocol implementation (Fetch or Push \noperation) as main-task, but Merge also looks interesting. What is more, \nI perceive Merge and Fetch operations as most wanted, because being on \nproject critical-path, blocking implementation of other tasks. Merge \nseems also to be used very often itself.\n\nCurrent implementation status:\nThere is currently no Eclipse (GUI, workspace logic) code directly for \neach of main tasks.\nWhat about jgit? I haven't looked at details of implementation yet \n(sorry, I'm starting), but...\nFor Fetch or Push: I'll need to implement protocol(s) for sure: git, ssh \nprotocols first as wiki-recommends - wisely, I think. What about support \nfrom jgit internals: do I need to add some git structures implementation \nto accomplish Fetch or Push: like object packing, needed objects \ntracking? Or is almost everything available, so I just need to use this \nstructures and concentrate on upload/receive operation and protocol \nimplementation? In case of Fetch, I guess that Create Branch (easy?) \nimplementation is also needed. Is local Fetch or Push already supported \nin jgit? If not, I'd start from this. I've got also some doubts \nconcerning SSH vs git access protocols. Are git-receive-pack and \ngit-upload-pack used by both of these access protocols? If so, it make \nthings easier:)\nFor Merge: I'll need to implement 3-way merge algorithm. Wiki says that \none can look at Eclipse, if it is already implemented there. IMHO it's \nbetter to implement it at jgit level, independently of egit, basing on \noriginal git implementation, don't you think (I've seen that there are \nsome efforts to implement git plugin for NetMeans, basing on jgit \nlibrary)? I wonder how laborious this task is, i.e. as for Fetch/Push: \ndoes translation of this algorithm written in C to Java requires \nsignificant changes or improvements to existing jgit code?\n\nWhat do you think about importance of each task and what is your feeling \nabout time needed to implement each?\n\n\nAt the end, few words about me, what you could expect:\nI'm a BSc/MSc undergraduate of a Computer Science course at Poznan \nUniversity of Technology (Poland). My main areas of interests are \ndistributed systems and software engineering, especially quality of \nsoftware. I'm quite experienced Java developer; and C is my \"second\" \nlanguage, so I can analyze existing git implementation. I've finished \nEclipse Summer School workshop some time ago - on Eclipse plugins \ndevelopment, so I've got some knowledge on Eclipse internals. I'm ready \nto implement protocol or algorithm when needed.\nI've got some experiences with JSch (bad experience...) and Trilead SSH \n(much more postive) - BSD-licensed SSH implementations for Java.\n\nTo this time I was working on many smaller projects, and one bigger (>1 \nyear, BSc and grids related), mostly in small teams, sometimes \ndistributed. It seems to be great experience if I can join git community:)\n\nThank you for your attention, I'd appreciate any comments, expectations \nor info (answers)! If you want I can move to private discussion.\n\nPS BTW: I've wonder what \"Checkpoint project\" in Eclipse Team menu \nstands for?\n\n-- \nMarek Zawirski [zawir]\nmarek.zawirski@gmail.com\n"},{"id":"72724","messageId":"20080323075241.GL8410@spearce.org","threadId":"12810","inReplyTo":"47E532DD.7030901@gmail.com","subject":"Re: [SoC] egit: pre-proposal, problem recognition","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2008-03-23T07:52:41Z","receivedAt":"2008-03-23T07:52:41Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Marek Zawirski <marek.zawirski@gmail.com> wrote:\n> \n> Let's start from some clean-up:\n> http://git.or.cz/gitwiki/EclipsePluginWishlist - isn't this site a \n> little outdated? It appears that tasks: Commit, Switch Branch (without \n> dirty workspace/merge support) are already done, aren't they?\n\nYea, I think you may be right.  I haven't been too current on egit\nlately, but I think these did get implemented.  Sometimes the wiki\nis out of date.  Happens because we would rather be working on code\nthan updating the wiki.  :)\n\n> Some operations look for me as rather straight-forward to implement - \n> not appropriate for a whole GSoC project (or do I underestimate?). \n> Namely: Create/Delete Branch, Create/Delete Tag, Gitignore, Checkout(?).\n\nI think you are right.  Doing all of them might be a GSoC project,\nbut a lot of it is just busy work and not that interesting of a\nchallenge.  Sure, it has to be done by someone, and everyone will\nappreciate the effort once its complete, especially if its done well.\nBut doing just one of them as a GSoC project would be too small.\n\n> GSoC2008 site states, that most wanted tasks are (that's reasonable) \n> Push and Merge implementation. Fetch operation also looks to be not \n> implemented yet?\n\nFetch and clone are in progress.  Robin Rosenburg (the current egit\nmaintainer) has it just about finished and will probably contribute\nit soon.  But I think its going to cause merge conflicts with my own\nrevwalk work.  So that's why fetch isn't on the GSoC 2008 ideas list.\n\n> So what can I do:\n> I think that 1-2 from 3 main jgit+egit tasks (Push, Fetch, Merge) appear \n> to be well-sized for a GSoC project. IMO, there is also need for a lot \n> of smaller improvements in egit itself: preferences, preference page, \n> user-friendliness related: more icons and information, help in dialogs, \n> wizards, menus etc. I'm thinking of taking 1 main task - implementing \n> first jgit part, then egit part. And if I finish it before time, I could \n> work on set of such smaller improvements in egit itself, to make it \n> easier/nicer for user.\n\nYes, I agree with that, except no fetch, as it will hopefully merge\nbefore GSoC summer officially starts.  A lot of the polish you are\ntalking about leaving to the end of the project is critical for any\ngood GUI.  I would not mind seeing it worked once the major features\nare completed.\n\nI did want to start on push work myself.  But if a student comes\nalong and does it for me, then awesome. :)\n\n> operation) as main-task, but Merge also looks interesting. What is more, \n> I perceive Merge and Fetch operations as most wanted, because being on \n> project critical-path, blocking implementation of other tasks. Merge \n> seems also to be used very often itself.\n\nYes.  Lots of interesting git features (cherry-pick, revert, rebase)\nare heavily based upon diff/apply and merge.  diff/apply can be\nimplemented in terms of merge in many cases, and we do that a lot\nin C Git. So we do really need a working merge implementation.\n \n> Current implementation status:\n> There is currently no Eclipse (GUI, workspace logic) code directly for \n> each of main tasks.\n> What about jgit? I haven't looked at details of implementation yet \n> (sorry, I'm starting), but...\n\nYea, aside from fetch there is no support yet in jgit for any of\nthe main tasks you were talking about, and the fetch part hasn't\nmerged to the public egit tree yet.\n\n> For Fetch or Push: I'll need to implement protocol(s) for sure: git, ssh \n> protocols first as wiki-recommends - wisely, I think. What about support \n> from jgit internals: do I need to add some git structures implementation \n> to accomplish Fetch or Push: like object packing, needed objects \n> tracking?\n\nThe object packing (aka git-pack-objects in Java) is required\nfor push.  Object tracking to feed the packer is almost finished\nin my revwalk branch, which also has not merged yet.  I started\nthat work to improve the performance and feature capabilities of\nthe History view, but its also to provide the object enumeration\nfunctions required for the packfile generator, which is needed for\npush to be implemented.\n\n> Or is almost everything available, so I just need to use this \n> structures and concentrate on upload/receive operation and protocol \n> implementation?\n\nSome of it is there.  The packer isn't, and the packer is a key\npart of the protocol.  Its what is actually doing the data transfer.\nThe command part of the protocol is actually fairly simple, and is\neven easier on the push side (the fetch side is more complex).\n\n> I've got also some doubts \n> concerning SSH vs git access protocols. Are git-receive-pack and \n> git-upload-pack used by both of these access protocols? If so, it make \n> things easier:)\n\nYes.  If you dig into the C implementation what we are actually doing for\nfetch over SSH is:\n\n\tssh user@hostname git-upload-pack path/to/project.git\n\nand for push:\n\n\tssh user@hostname git-receive-pack path/to/project.git\n\nNow the git:// native protocol just opens a TCP connection to a\nserver running git-daemon, sends the service name and directory\n(which is the last args you see above to SSH), and then the daemon\nexecutes that program.  After that point the SSH vs. native Git\nare identical.  The major reason for SSH wrapping is its obvious\nsecurity benefits.  The major reason for the native Git protocol\nis efficient anonymous publication, especially for popular open\nsource projects.\n\n> For Merge: I'll need to implement 3-way merge algorithm. Wiki says that \n> one can look at Eclipse, if it is already implemented there. IMHO it's \n> better to implement it at jgit level, independently of egit, basing on \n> original git implementation, don't you think (I've seen that there are \n> some efforts to implement git plugin for NetMeans, basing on jgit \n> library)? I wonder how laborious this task is, i.e. as for Fetch/Push: \n> does translation of this algorithm written in C to Java requires \n> significant changes or improvements to existing jgit code?\n\nYea, I wrote that statement about using merge code from Eclipse,\nbut lately I have been thinking that is a bad idea.  Another person\nhas stated to talk about using jgit to build a Git NetBeans plugin,\nand in another case there may be some idea of compiling jgit to\nCLR and using it for a Git Mono plugin.\n\nThere is currently little-to-no merge support in jgit.  All of it\nneeds to be ported in, or obtained from a suitable Java library that\nwe can embed and ship as part of the package.  C Git for example\nembeds and ships libxdiff for most of its diff/merge code.\n \n> What do you think about importance of each task and what is your feeling \n> about time needed to implement each?\n\nI think merge is a huge task, especially if you have to do your own\nfile level merge implementation by porting in say libxdiff to Java.\nFocusing on merge may take the better part (or all!) of a GSoC\nsummer, but if you finished early then I would suggest doing the\nmuch needed UI additions like you discussed above.\n \n> I've got some experiences with JSch (bad experience...) and Trilead SSH \n> (much more postive) - BSD-licensed SSH implementations for Java.\n\nInteresting that JSch wasn't a good experience.  Eclipse has just made it\nan official part of the core platform, even without the IDE and its CVS\nplugin.  I was sort of hoping that given it is now fully integrated into\nEclipse, and its key management is just part of the workspace, that we\ncould take advantage of that in egit.\n \n> To this time I was working on many smaller projects, and one bigger (>1 \n> year, BSc and grids related), mostly in small teams, sometimes \n> distributed. It seems to be great experience if I can join git community:)\n\nYou can join any time.  GSoC is just a good execuse.  :)\n\n> PS BTW: I've wonder what \"Checkpoint project\" in Eclipse Team menu \n> stands for?\n\nThat's my fault.  A long time ago egit stored the workspace back\nout as trees, rather than using the standard .git/index file.\nIt was slow and cost a lot of time, so I tried to put that activity\nonto a low priority background job.  The job caused more problems,\nso Robin got rid of it.  But the menu option to allow the user to\nforce a checkpoint is still there.\n\nA checkpoint lets egit construct a tree object for the current\nfiles, so a commit is faster as all of the blobs are already in the\nobject store.  But with the index and add (aka stage) now in egit,\nand the commit dialog, that is less of an issue as the tree gets\ncreated from the index, which you already staged files into.\n\nIn short, that menu option needs to come out at some point.\n\n-- \nShawn.\n"},{"id":"72826","messageId":"200803232244.11031.robin.rosenberg.lists@dewire.com","threadId":"12810","inReplyTo":"20080323075241.GL8410@spearce.org","subject":"Re: [SoC] egit: pre-proposal, problem recognition","fromName":"Robin Rosenberg","fromEmail":"robin.rosenberg.lists@dewire.com","sentAt":"2008-03-23T22:44:10Z","receivedAt":"2008-03-23T22:44:10Z","isPatch":false,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"Den Sunday 23 March 2008 07.52.41 skrev Shawn O. Pearce:\n> Marek Zawirski <marek.zawirski@gmail.com> wrote:\n\nWelcome Marek.\n\n> > Let's start from some clean-up:\n> > http://git.or.cz/gitwiki/EclipsePluginWishlist - isn't this site a\n> > little outdated? It appears that tasks: Commit, Switch Branch (without\n> > dirty workspace/merge support) are already done, aren't they?\n>\n> Yea, I think you may be right.  I haven't been too current on egit\n> lately, but I think these did get implemented.  Sometimes the wiki\n> is out of date.  Happens because we would rather be working on code\n> than updating the wiki.  :)\n\nDeleting some stuff isn't that hard once you realize it needs to be done. \nDone.\n\n> > Some operations look for me as rather straight-forward to implement -\n> > not appropriate for a whole GSoC project (or do I underestimate?).\n> > Namely: Create/Delete Branch, Create/Delete Tag, Gitignore, Checkout(?).\n>\n> I think you are right.  Doing all of them might be a GSoC project,\n> but a lot of it is just busy work and not that interesting of a\n> challenge.  Sure, it has to be done by someone, and everyone will\n> appreciate the effort once its complete, especially if its done well.\n> But doing just one of them as a GSoC project would be too small.\nI agree it's not really the challenge a GSoc project should be. Leave for \nnewcomers that wants something simple to chew. We can do that a patch\nat a time.\n\n> > GSoC2008 site states, that most wanted tasks are (that's reasonable)\n> > Push and Merge implementation. Fetch operation also looks to be not\n> > implemented yet?\n>\n> Fetch and clone are in progress.  Robin Rosenburg (the current egit\n> maintainer) has it just about finished and will probably contribute\n> it soon.  But I think its going to cause merge conflicts with my own\n> revwalk work.  So that's why fetch isn't on the GSoC 2008 ideas list.\nYes, fetch (and clone) over git and git+ssh works on my machine. I did not go \ninto the http based version which is a different story altoghether so it is \nstill open.\n\n> > So what can I do:\n> > I think that 1-2 from 3 main jgit+egit tasks (Push, Fetch, Merge) appear\n> > to be well-sized for a GSoC project. IMO, there is also need for a lot\n> > of smaller improvements in egit itself: preferences, preference page,\n> > user-friendliness related: more icons and information, help in dialogs,\n> > wizards, menus etc. I'm thinking of taking 1 main task - implementing\n> > first jgit part, then egit part. And if I finish it before time, I could\n> > work on set of such smaller improvements in egit itself, to make it\n> > easier/nicer for user.\n>\n> Yes, I agree with that, except no fetch, as it will hopefully merge\n> before GSoC summer officially starts.  A lot of the polish you are\n> talking about leaving to the end of the project is critical for any\n> good GUI.  I would not mind seeing it worked once the major features\n> are completed.\n>\n> I did want to start on push work myself.  But if a student comes\n> along and does it for me, then awesome. :)\n\nPush implies writing a highly efficient packing mechanism (actually could\nwork without the efficiency in form of delya packing, but I'm not sure we want \nthat).\n\n> > operation) as main-task, but Merge also looks interesting. What is more,\n> > I perceive Merge and Fetch operations as most wanted, because being on\n> > project critical-path, blocking implementation of other tasks. Merge\n> > seems also to be used very often itself.\n>\n> Yes.  Lots of interesting git features (cherry-pick, revert, rebase)\n> are heavily based upon diff/apply and merge.  diff/apply can be\n> implemented in terms of merge in many cases, and we do that a lot\n> in C Git. So we do really need a working merge implementation.\n\nA subproject of that is making graphical merge resolution inside Eclipse. That\nmight not be such a big project though depending on how much support\nthere is in eclipse. I haven't looked into it really.\n\n> > For Merge: I'll need to implement 3-way merge algorithm. Wiki says that\n> > one can look at Eclipse, if it is already implemented there. IMHO it's\n> > better to implement it at jgit level, independently of egit, basing on\n> > original git implementation, don't you think (I've seen that there are\n> > some efforts to implement git plugin for NetMeans, basing on jgit\n> > library)? I wonder how laborious this task is, i.e. as for Fetch/Push:\n> > does translation of this algorithm written in C to Java requires\n> > significant changes or improvements to existing jgit code?\n>\n> Yea, I wrote that statement about using merge code from Eclipse,\n> but lately I have been thinking that is a bad idea.  Another person\n> has stated to talk about using jgit to build a Git NetBeans plugin,\n> and in another case there may be some idea of compiling jgit to\n> CLR and using it for a Git Mono plugin.\nMy mind wanders...\n\n> There is currently little-to-no merge support in jgit.  All of it\n> needs to be ported in, or obtained from a suitable Java library that\n> we can embed and ship as part of the package.  C Git for example\n> embeds and ships libxdiff for most of its diff/merge code.\n>\n> > What do you think about importance of each task and what is your feeling\n> > about time needed to implement each?\n>\n> I think merge is a huge task, especially if you have to do your own\n> file level merge implementation by porting in say libxdiff to Java.\n> Focusing on merge may take the better part (or all!) of a GSoC\n> summer, but if you finished early then I would suggest doing the\n> much needed UI additions like you discussed above.\n>\n> > I've got some experiences with JSch (bad experience...) and Trilead SSH\n> > (much more postive) - BSD-licensed SSH implementations for Java.\n>\n> Interesting that JSch wasn't a good experience.  Eclipse has just made it\n> an official part of the core platform, even without the IDE and its CVS\n> plugin.  I was sort of hoping that given it is now fully integrated into\n> Eclipse, and its key management is just part of the workspace, that we\n> could take advantage of that in egit.\nThe current fetch uses Ganymedes for SSH. It seesm to work well and has\nlots of features for key management. There is an SHA-1 implementation there\nalso that should be a bit faster than Sun's default.\n\n>\n> > To this time I was working on many smaller projects, and one bigger (>1\n> > year, BSc and grids related), mostly in small teams, sometimes\n> > distributed. It seems to be great experience if I can join git\n> > community:)\n>\n> You can join any time.  GSoC is just a good execuse.  :)\n>\n> > PS BTW: I've wonder what \"Checkpoint project\" in Eclipse Team menu\n> > stands for?\n>\n> That's my fault.  A long time ago egit stored the workspace back\n> out as trees, rather than using the standard .git/index file.\n> It was slow and cost a lot of time, so I tried to put that activity\n> onto a low priority background job.  The job caused more problems,\n> so Robin got rid of it.  But the menu option to allow the user to\n> force a checkpoint is still there.\nI left it and almost forgot about it. We should probably drop it completely.\n\n(sorry for not cleaning up my response fully here. bedtime)\n\n-- robin\n"},{"id":"73049","messageId":"47E92875.6030208@gmail.com","threadId":"12810","inReplyTo":"200803232244.11031.robin.rosenberg.lists@dewire.com","subject":"Re: [SoC] egit: pre-proposal, problem recognition","fromName":"Marek Zawirski","fromEmail":"marek.zawirski@gmail.com","sentAt":"2008-03-25T16:29:41Z","receivedAt":"2008-03-25T16:29:41Z","isPatch":false,"sender":{"key":"marek.zawirski@gmail.com","avatar":null},"body":"\nHi, coming back to git-dev. Was nice to get some valuable comments from \nShawn and Robin :]\n\nRobin Rosenberg <robin.rosenberg.lists@dewire.com> wrote:\n>> Fetch and clone are in progress.  Robin Rosenburg (the current egit\n>> maintainer) has it just about finished and will probably contribute\n>> it soon.  But I think its going to cause merge conflicts with my own\n>> revwalk work.  So that's why fetch isn't on the GSoC 2008 ideas list.\n> Yes, fetch (and clone) over git and git+ssh works on my machine. I did not go \n> into the http based version which is a different story altoghether so it is \n> still open.\n> \n>> I did want to start on push work myself.  But if a student comes\n>> along and does it for me, then awesome. :)\n> \n> Push implies writing a highly efficient packing mechanism (actually could\n> work without the efficiency in form of delya packing, but I'm not sure we want \n> that).\n\nI've tried to look at this problem closer.\nI've seen that egit supports packed objects reading already. What makes\nme not-sleeping is builtin-pack-objects.c code - mentioned packs\ncreation support. Hacking git story.... IMHO porting it into Java is a \nreally big task , also because of its dependencies - especially \ndelta/diff related code. It looks for me that it could be as difficult \nas merge support, or even harder :/\n\nSo... by not efficient packing you probably mean only compressing \nobjects (+possibly arranging some order), but not finding deltas? I \nbelieve that the main reason why Robin said that he don't know whether \nit is wanted, is that when we are creating and sending such packs, \nthey'll be stored on remote side in such inefficient way. Until repo \nadmin make some cleanup (packing). I suspect that it's not enough reason \nfor creating git-receive-pack --repack option (configuration/protocol \nnegotiated, in SSH case, simply forced by client)?\nBTW it shows that git receiver is very trusty (efficiency on top?) for\nrepo users: not only about what they transfer, but also about the way\nthey transfer and format it.\n\nAnyway, I though that even push code without highly efficient\npacking mechanism may be valuable for a meantime - at least as a base \nfor further enhancements. I imagine that it maybe easy to abstract packs \ncreation algorithm, that could be enhanced later. While rest of a commit \noperation would be already implemented.\nIn a meantime user could get warning in Commit dialog, that produced \npack is not so efficient (yeah, not so pretty...).\n\n>> Yes.  Lots of interesting git features (cherry-pick, revert, rebase)\n>> are heavily based upon diff/apply and merge.  diff/apply can be\n>> implemented in terms of merge in many cases, and we do that a lot\n>> in C Git. So we do really need a working merge implementation.\n\n.. so I now see that merge and packing operations look like most needed \nand most hard to do;)\n\n> A subproject of that is making graphical merge resolution inside Eclipse. That\n> might not be such a big project though depending on how much support\n> there is in eclipse. I haven't looked into it really.\n\nI've been looking around. There is general Eclipse Synchronization API \nas part of Team API, and related Synchronize View to provide user \nsimilar look&feel across different synchronization schemes.\nSubclipse and CVS for Eclipse implements this API. I'm not very \nexperienced CVS user, but saw that there are 2 Synchronization Views for \nCVS: for synchronization with repository (head?) and merging/conflicts \nresolutions. The second one is easier, and is what you probably mean. So \nthere is pretty nice support from Eclipse. However, without stable merge \nAPI (not existing yet) is hard to do anything around that.\n\nAt the beginning, there could be just Compare Editor (CompareUI) for \nconflicting file edition without whole synchronization perspective and \nview  - not a big project. It is nice Eclipse editor, that \"only\" needs \ntree of DiffNode objects as input: result tree of three-way or two-way \nmerge algorithm. Maybe some ad-hoc version could be provided without \nmerge API (not sure), basing on git-merge result file with marked \nconflicts for creation of DiffNode tree (showing just two-way merge).\n\n\n>> Yea, I wrote that statement about using merge code from Eclipse,\n>> but lately I have been thinking that is a bad idea.  Another person\n>> has stated to talk about using jgit to build a Git NetBeans plugin,\n>> and in another case there may be some idea of compiling jgit to\n>> CLR and using it for a Git Mono plugin.\n\nWow;) However, it seems that Microsoft is abandonning J# language? Don't \nknow what is current status, I've been coding in C# only.\n\n>> There is currently little-to-no merge support in jgit.  All of it\n>> needs to be ported in, or obtained from a suitable Java library that\n>> we can embed and ship as part of the package.  C Git for example\n>> embeds and ships libxdiff for most of its diff/merge code.\n\nThat makes things harder. On the other hand, some people also faced this \nproblem before. SVNKit (\"jgit for svn\") provides some 3-way merge and \nDifferencer class from Eclipse org.eclipse.compare, possibly used by \nCVS. However, both of these solutions are product specific, so the code \n(if used; license issues) need to be copied & adapted for jgit. \nEspecially SVNKit seems to depend on their own classes.\n\n>> I think merge is a huge task, especially if you have to do your own\n>> file level merge implementation by porting in say libxdiff to Java.\n>> Focusing on merge may take the better part (or all!) of a GSoC\n>> summer, but if you finished early then I would suggest doing the\n>> much needed UI additions like you discussed above.\n\nWell, words \"better part (or all!)\" doesn't sound very enthiusiatic for \nme... (explanation below)\n\n>> Interesting that JSch wasn't a good experience.  Eclipse has just made it\n>> an official part of the core platform, even without the IDE and its CVS\n>> plugin.  I was sort of hoping that given it is now fully integrated into\n>> Eclipse, and its key management is just part of the workspace, that we\n>> could take advantage of that in egit.\n> The current fetch uses Ganymedes for SSH. It seesm to work well and has\n> lots of features for key management. There is an SHA-1 implementation there\n> also that should be a bit faster than Sun's default.\n\nTrilead for SSH is successor of Ganymed for SSH, as WWW tells. Yes, it \nwas surprising for me, that JSch became official Eclipse core part. \nAFAIR especially annoying things were 1) you had to do polling for \nchecking results of some operations(!) 2) no javadoc. I thought that in \n21st century people used to blocking operations, or non-blocking with \nListener pattern and so on;> Or maybe something changed in library or \nI'm stupid and couldn't read library usage examples correctly.\nBoth libraries uses same OpenSSH key formats possibly, so maybe key \nmanagement in workspace is possible even if case of \"mixing\" them.\n\n>> You can join any time.  GSoC is just a good execuse.  :)\n\nEspecially good if I don't have much of free time except holidays for \nGSoC :)\n\nTo sum up a little. If you don't mind much, I would prefer doing some \njgit task that will not fill my whole project, as I would like to do \nsome Eclipse-related stuff also. Full merge implementation (with \ndiff&merge algorithm adaptation) and full push operation (with efficient \npacking)  seems to be tasks that may take a really long time, as I've \nlearned from your comments.\n\nMy reasons for interesting in tasks that are related to Eclipse are:\n- it's nice to play with Eclipse, learn it more\n- don't want to dig into real git internals for whole summer, if \npossible; I believe that coming into details for git-newbie may take \nmuch time\n- There is friendly IBM Eclipse Support Center team in Poznan. As they \nare very enthusiastic about supporting Eclipse-related products, they've \nproposed to support GSOC Eclipse-related projects for free:) This means \nthat I can work on GSoC in their office and get advices, ask for their \nknowledge (they are pros, Eclipse Foundation contributors) anytime. I \nthink it's reasonable to benefit from such proposal.\n\nReasons for taking tasks related more to git:\n- I always appreciate some network/distributed stuff ;)\n- possibly interesting algorithms or Java profiling\n- merge&packing is much NEEDED\n\nSo I would balance them if possible. For example, providing push \nimplementation for GIT and SSH with some simple (extensible) packing \nalgorithm at first and/or providing HTTP-based (commit walkers as you \nname them) fetch. Then moving to Eclipse/UI related stuff. What do you \nthink?\n\nI also see that project is very dynamic, so in 2 months some things may \nchange, even some basic merge may support may come? If you agree, I can \nmake in my application/proposal longer tasks list with priorities, and \nannotation that specific tasks for implementation will be chosen from \ntop, depending on what is current dependencies status.\n\nMaybe it would be easier to chat on IRC for us. What are your nicks if \nyou are there (mine: zawir)?\n\nAgain, RFC & thanks for support :)\n\n-- \nMarek Zawirski [zawir]\nmarek.zawirski@gmail.com\n"}]}