git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Core and Not-So Core

From
Jon Seymour <jon.seymour@gmail.com>
Date
May 11, 2005, 14:40 UTC
Message-ID
<2cfc4032050511074038d66089@mail.gmail.com>
In-Reply-To
<4281EAB5.3020006@peralex.com>
On 5/11/05, Noel Grandin <noel@peralex.com> wrote:
Show 8 quoted lines
> Hi
> 
> Note that eclipse in particular has a fairly complicated repository
> provider interface.
> The subversion plugin developers (the subclipse project) took quite a
> while to implement their stuff.
> Basing your stuff off of their code would be a good idea.
> 
Noel,

Thanks for the info. I'll certainly have a look at what the subclipse folks did as I am sure it will be helpful to understand the strategy. I do think we are in a slightly different situation here as we don't quite have a stable library interface to git yet - Brad Roberts work notwithstanding.

The repository API in pure Java is almost a no-brainer since Linus has done such a good job in keeping the repository specification simple and unambiguous.

A Java workspace API can take advantage of the abstraction and GUI facilities that Java and Eclipse afford so will naturally be different in form to the existing command line tools for manipulating the git index. Certainly, there will be similarities - aspects of the 3-way merge, for example, but there will be differences too - workspace change detection will be somewhat assisted by the change notification framework in Eclipse and won't require as much manual intervention.

Show 7 quoted lines
> Also, they worked in 2 stages - in the first stage, they created
> something called the JavaHL interface, behind which they talked to the
> subversion C libraries using JNI.
> Then they created a pure-java implemenation of the subversion C
> libraries which also implemented the JavaHL interface, allowing them to
> compare and contrast the behaviour.
>

At this stage, my thoughts are to implement a listener pattern to keep the git index up to date, and I may well implement that by calling out the the C git-update-cache executable. This can run in a background thread so it needn't be a huge drag on interactive user performance.

Anyway, thanks for your input.
jon.
Previous: Noel GrandinNext: Juliusz Chroboczek
Message 25 of 40 in “Core and Not-So Core”
  1. Jon SeymourMay 10, 2005
  2. David WoodhouseMay 10, 2005
  3. Eduardo Teixeira DiasMay 10, 2005
  4. David WoodhouseMay 10, 2005
  5. Eduardo Teixeira DiasMay 10, 2005
  6. Diego CallejaMay 10, 2005
  7. Eduardo Teixeira DiasMay 10, 2005
  8. Diego CallejaMay 10, 2005
  9. Eduardo Teixeira DiasMay 10, 2005
  10. Eduardo Teixeira DiasMay 10, 2005
  11. Petr BaudisMay 10, 2005
  12. Andreas GalMay 10, 2005
  13. James PurserMay 10, 2005
  14. Christoph HellwigMay 11, 2005
  15. Jon SeymourMay 11, 2005
  16. Jon SeymourMay 10, 2005
  17. David WoodhouseMay 10, 2005
  18. Daniel BarkalowMay 10, 2005
  19. Petr BaudisMay 10, 2005
  20. Jon SeymourMay 11, 2005
  21. Peter WilliamsMay 11, 2005
  22. Nicolas PitreMay 11, 2005
  23. Jon SeymourMay 11, 2005
  24. Noel GrandinMay 11, 2005
  25. Jon SeymourMay 11, 2005
  26. Juliusz ChroboczekMay 18, 2005
  27. Jon SeymourMay 10, 2005
  28. David WoodhouseMay 10, 2005
  29. Jon SeymourMay 10, 2005
  30. Christoph HellwigMay 10, 2005
  31. Rik van RielMay 11, 2005
  32. Jon SeymourMay 11, 2005
  33. Petr BaudisMay 11, 2005
  34. Jon SeymourMay 10, 2005
  35. Davide LibenziMay 10, 2005
  36. Jon SeymourMay 10, 2005
  37. Petr BaudisMay 10, 2005
  38. Jon SeymourMay 10, 2005
  39. Daniel BarkalowMay 11, 2005
  40. Jon SeymourMay 11, 2005

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.