Re: [PATCH] libgit

From: Mike Taht <mike.taht@timesys.com>
Date: Apr 17, 2005, 08:08 UTC
Message-ID: <42621993.10800@timesys.com>
In-Reply-To: <Pine.LNX.4.44.0504170027500.2625-100000@bellevue.puremagic.com>

Brad Roberts wrote:

Show 14 quoted lines

>>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....

Show 8 quoted lines

> 
> 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."