threads / discuss / 8720

Working on builtin-commit

Subject: Working on builtin-commit

## tl;dr

One message between Jun 25, 2007 and Jun 25, 2007.

replies: 0people: 1as markdown or json

Kristian Høgsberg· Jun 25, 2007, 19:27 UTC · lore
Hi,

To avoid duplication of work, here's a short heads up. I've started working on porting git-commit.sh (and status) to builtins. It's still work in progress, and nowhere near a full-time effort, but to prevent doing double work as with builtin-tag, I thought I'd let the list know. I have a repo over here:

	git://people.freedesktop.org/~krh/git.git
and the code is browsable here:
	http://cgit.freedesktop.org/~krh/git.git
on the 'builtin-commit' branch.

It's just a snapshot of my current progress, so don't slam my lack of error checking etc just yet. The work also needs to be split out in a few patches (eg the read_pipe stuff). One thing that might be interesting to discuss now, though, is my approach to option parsing. I realize real men do this by hand using a lot of strcmp's, but I broke down and wrote a little option parser. You give it a pointer to argv and an array of these:

	struct option {
		enum option_type type;
		const char *long_name;
		char short_name;
		void *value;
	};
with
	enum option_type {
		OPTION_NONE,
		OPTION_STRING,
		OPTION_INTEGER,
		OPTION_LAST
	};

and it goes and parses the command line. As the shell script, it accepts all abreviations of long options, eg all of --messa doit, --message=doit, -mdoit, -m doit, for the long_name="message"; short_name='m' case. Ambiguous abbreviations are resolved according to the order the options appears in the array. I've kept it as simple as possible and it works well for builtin-commit.c. It's obviously useful for other commands, but my goal here is to get git-commit.sh ported to C, not to host a flamewar over the option parser API and whether we should port other builtins.

cheers, Kristian

← back to recent threads