Any overview available on jgit codebase?

[Farrukh Najmi <farrukh@wellfleetsoftware.com>]

I am looking for any available docs that will help me learn the layout 
of the jgit code base.

In the ideal world here is what would help newbies get productive with 
the project quickly:

1. Have a clear one line description available in the javadocs for each 
package.
2. Have a clear one line description available in javadocs for each 
class in each package.
3. Have a clear one line description available in javadocs for each 
method in each class.

I would gladly do this and contribute the changes back but its a chicken 
and egg situation since I do not know the code base.

I realize its a lot to ask but would anyone familiar with code base 
volunteer to do at least (1) above?

At minimum could anyone tell me what packages and classes to look at in 
order to make changes to jgit so it uses a database instead of 
filesystem to references.

Lastly, where can I find information on the structure of the .git directory?

Thanks for your help.

Kyle Moffett wrote:
> On Thu, Nov 13, 2008 at 3:27 PM, Farrukh Najmi
> <farrukh@wellfleetsoftware.com> wrote:
>   
>> The problem I am trying to solve is this. In my service I need to store
>> metadata in a relational db and content in git such that both either commit
>> or not in a single transaction. If one commits and the other does not that
>> is a serious integrity issue. Seems to me, two phase commit would be the
>> right solution for that in the long run. This what JDBC + JMS topologies do.
>>     
>
> That's really easy!  First tweak jgit so that *instead* of using
> .git/refs, it uses your database to store references and exports them
> on a routine basis to .git/refs for debugging purposes.  Then, for
> each database update:
>
> (1)  Start transaction
> (2)  Commit the change to GIT (adds ref update to the transaction)
> (3)  Make other metadata updates
> (4)  Commit transaction
>
> Then set up periodic garbage collection and you're done!  If the
> transaction is aborted, there will simply be a bunch of random loose
> objects in the git repository, which will be cleaned up the next time
> you garbage collect.  The ref update will be atomic and conditional
> with the rest of the transaction, and in git the *only* part that
> really matters for atomicity is the ref.
>
> Cheers,
> Kyle Moffett
>
>   


-- 
Regards,
Farrukh Najmi

Web: http://www.wellfleetsoftware.com