[PATCH] libgit

[PATCH] libgit

[Mike Taht]

commit b0550573055abcf8ad19dcb8a036c32dd00a3be4
tree b77882b170769c07732381b9f19ff2dd5c9f1520
parent 866b4aea9313513612f2b0d66814a2f526d17f21
author Mike Taht <m@picketwyre.com> 1113704772 -0700
committer Mike Taht <m@ipbx.taht.net> 1113704772 -0700

looks my 1878 line patch to convert git to libgit got eaten by vger..
I put it up at http://pbx.picketwyre.com/~mtaht/libgit.patch if anyone 
wants to comment. from my log:

Converted git to libgit. Moved all the main() calls into a single 
multi-call binary - git-main.
Made extern a bunch of functions that were static. Verified it at least 
still minimally worked.
Note: this is only a first step towards creating a generic library. 
Figuring out what functions and variables *truly* need to be exported, 
renaming them to a git_<function> api, making it thread safe
... and not least of all, keeping up with everybody working out of the 
base tree... are problems that remain. Also - cleaning up the UI.

Re: [PATCH] libgit

[Randy.Dunlap]

On Sat, 16 Apr 2005 20:12:56 -0700 Mike Taht wrote:

| commit b0550573055abcf8ad19dcb8a036c32dd00a3be4
| tree b77882b170769c07732381b9f19ff2dd5c9f1520
| parent 866b4aea9313513612f2b0d66814a2f526d17f21
| author Mike Taht <m@picketwyre.com> 1113704772 -0700
| committer Mike Taht <m@ipbx.taht.net> 1113704772 -0700
| 
| looks my 1878 line patch to convert git to libgit got eaten by vger..
| I put it up at http://pbx.picketwyre.com/~mtaht/libgit.patch if anyone 
| wants to comment. from my log:

Connection refused.

---
~Randy

Re: [PATCH] libgit

[Mike Taht]

Fixed.

Randy.Dunlap wrote:
> On Sat, 16 Apr 2005 20:12:56 -0700 Mike Taht wrote:
> 
> | commit b0550573055abcf8ad19dcb8a036c32dd00a3be4
> | tree b77882b170769c07732381b9f19ff2dd5c9f1520
> | parent 866b4aea9313513612f2b0d66814a2f526d17f21
> | author Mike Taht <m@picketwyre.com> 1113704772 -0700
> | committer Mike Taht <m@ipbx.taht.net> 1113704772 -0700
> | 
> | looks my 1878 line patch to convert git to libgit got eaten by vger..
> | I put it up at http://pbx.picketwyre.com/~mtaht/libgit.patch if anyone 
> | wants to comment. from my log:
> 
> Connection refused.
> 
> ---
> ~Randy


-- 

Mike Taht


   "FLASH!  Intelligence of mankind decreasing.  Details at ... uh, when
the little hand is on the ...."

Re: [PATCH] libgit

[Brad Roberts]

> Converted git to libgit. Moved all the main() calls into a single
> multi-call binary - git-main.
> Made extern a bunch of functions that were static. Verified it at least
> still minimally worked.
> Note: this is only a first step towards creating a generic library.
> Figuring out what functions and variables *truly* need to be exported,
> renaming them to a git_<function> api, making it thread safe
> ... and not least of all, keeping up with everybody working out of the
> base tree... are problems that remain. Also - cleaning up the UI.

Why do all that static and main rearrangement?  It would be a lot simpler
and cleaner to simply rename the main's in place and add the new
dispatcher by itself.

Later,
Brad

Re: [PATCH] libgit

[Mike Taht]

Brad Roberts wrote:
>>Converted git to libgit. Moved all the main() calls into a single
>>multi-call binary - git-main.
>>Made extern a bunch of functions that were static. Verified it at least
>>still minimally worked.
>>Note: this is only a first step towards creating a generic library.
>>Figuring out what functions and variables *truly* need to be exported,
>>renaming them to a git_<function> api, making it thread safe
>>... and not least of all, keeping up with everybody working out of the
>>base tree... are problems that remain. Also - cleaning up the UI.
> 
> 
> Why do all that static and main rearrangement?  It would be a lot simpler
> and cleaner to simply rename the main's in place and add the new
> dispatcher by itself.

0) I like multi-call binaries.

1) I wanted to get a first pass at what functions needed to be exported, 
and pulling out the mains was the fastest way to see what might be  needed.

2) Agreed, about half of git-main.c needs to move back into the 
libraries, but that depends on deciding on the API for the formentioned 
functions... and leaving the mains parsing argv in the library itself 
seemed silly. So I moved them out. See 1)

In particular gotta chose the prefix itself git_<function> or 
cg_<_function> or cogito_<function>. I lean towards git_ myself - 
it'short and unique-looking, though I haven't verified that

When the useful to export functions are clearly identified they have to 
become named thus.

3) I'd really like to commonalize the UI and use longopts for the 
argument parsing. Linus indicated a preference for a certain argument 
order, longopts doesn't do that.

4) Like to make git thread safe (and ultimately, thread using - parallel 
diff, merge, fsck) and that means eliminating the globals, where 
appropriate. I've been thinking through the issues there (how about 
(GIT_THREAD)->some_variable and (GIT-GLOBAL)->some_variable where those 
define out when threads are disabled? Etc. There needs to be a git_init 
that does things like correctly and universally setting up the defaults, 
and atexit, etc, file locking needs to fixed...

5) I wanted to get something that still compiled, worked, and out for 
comment before I went to bed. :)

my current plan is to break out git.h back into it's subject 
"update-cache.h" etc, move all that into include/git, turn git.h into a 
master lazy man's include, come up with a scheme for the globals, get 
some sort of thread cleanliness and take a crack at making it shared.

and now to bed. All: Feel free to implement any of that....

> 
> Later,
> Brad
> 
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


-- 

Mike Taht


   "If you wait long enough, it will go away... after having done its 
damage.
If it was bad, it will be back."