Re: [jgit-dev] JGit Client API

[Christian Halstrick <christian.halstrick@xxxxxxxxx>]

Hi,

I agree that we need Command specific classes representing the options
you want to specify. To summarize your responses I see two different
alternatives:

a) Traditional Options class:
- A GitPorcelain class having methods like public ...
<command>(<commandOptions> opt)
- <command>Options classes with setters for each option. These
traditional setter methods return void.

b) Command Builders:
- A GitPorcelain class having methods like public <command>Action <command>()
- <command>Action classes with setters for each option. Each setter
returns the updated <command>Action class (this allows chaining
like...Action.setX().setY() )
- each <command>Action has methods with trigger the execution of the
command. E.g. CommitAction has a commit() method with fires the commit
with all the options
  which have been collected up to know.

I played with the options especially from the point of view of the
user of our Git classes. How easy can I fire a commit with a lot of
options, how many lines of code do I need and how
much would a jgit-newbie be surprised by the kind of methods he has to use.
The newbie would be least surprised by a plain java method having
neither options nor builder classes. But sheer number of optional
parameters a git command may have rules out this option in Java (for
other languages having better support for optional params that
decision may be different).
And for me the next best alternative is option b) , the Builder
proposal from Shawn. I would hate to be forced to explicitly
instantiate <command>Options classes when just want to fire a simple
git command with one parameter.

Ciao
  Chris