Re: [jgit-dev] JGit Client API

[Christian Halstrick <christian.halstrick@xxxxxxxxx>]

Hi,

On Tue, Apr 20, 2010 at 14:10, Jonas Fonseca <jonas.fonseca@xxxxxxxxx> wrote:
> On Sun, Apr 18, 2010 at 16:13, Christian Halstrick
> <christian.halstrick@xxxxxxxxx> wrote:
>> And for me the next best alternative is option b) , the Builder
>> proposal from Shawn.
>
> I went with a builder API when I started to refactor the JGit code
> used in the NetBeans plugin:
>
>  - http://github.com/jonas/nbgit/tree/master/src/org/nbgit/client/
>
> And it has worked quite nicely, especially to make tests readable. I

+1, that is one of my hopes: I would like that contributors can at
least write easily tests for their new features although they don't
know in depth how to do a commit, add something to the index and so
one. In the moment it is quite demotivating for jgit-newbies to write
a test because even for the basic stuff you have to do a lot of
cut&paste to get basic git functionality.

That's very valueable info for us that a builder API on top of JGit
does work good.

> have a few requests for such an API. First, that there is some kind of
> builder to manipulate the index. While the new DirCache API is
> generally nice it is not as easy to use as the now deprecated
> GitIndex. Second, it would be nice to also have a builder to generate

The DirCache API was exactly the reason why I started this initiative.
I contributed a working content merge algorithm some time ago. Now I
am struggling to incorporate this algorithm into a merge command and
one big problem is how to deal with dircache. I need a "git checkout"
or a "git read-tree" working with DirCache and thought before I put my
implementation deep down in JGit lib's let's make this functionality
visible to developers new to JGit.

But to limit the scope of the API discussed in this thread: I would
like to add only and exactly what is available as git.git command.
E.g. currently I can think about the "add" command ... but not about
some low-level builder API to populate an index. Not that we don't
need it, but just don't focus on that now.

> a tree diff of changed paths for status and commit visualization,
> since it can be tricky wrt. comparing modes.

Some argument: currently I could think about a StatusCommand

> Finally, it is my impression that the JGit APIs generally try to avoid
> direct use of java.util.File prefering instead strings containing
> relative paths. NetBeans' VCS API makes extensive use of
> java.util.File and it can be error-prone to convert paths, e.g. past
> index out of bound exception in Repository.stripWorkDir(). At least,
> it is my impression that I ended up having 3 duplicate methods doing
> what Repository.stripWorkDir() did, before I found this method. I
> don't know if this still goes for someone new to JGit, however, would
> it be possible to have these builders take both?

Hmmm, I am not sure. I think there are often situations where git
commands take pathes but it is not required that you really have an
associated File in your workdir. Think about working with bare
repositories. But where it is really for sure that an appropriate file
has to exist (e.g. during git add <pathToFile>) of course the command
class may also have a setteer taking java.io.File.

Ciao
  Chris