Jeff King <peff@xxxxxxxx> writes: > I'm starting by writing run_status in C. Once that is working (which > should be soon), I believe it should suffice as a vanilla git-status > (do people actually do things like git-status with flags? It's not > documented, but it does work). Well, "git-status" is by definition (see list discussion when it was made into its current shape) a preview of "git-commit", so all the options are supported and needs to work with options. I just noticed that its documentation has not been updated, though. So I'd suggest, mildly, against naming your "run_status() equivalent" git-status. And if you follow through your plan, you would most likely have git-status _and_ git-commit both in C at about the same time when you finish. > I'm definitely in favor. > >> Will commit >> modified: Makefile (warning: further changed) > > I like it (the double-mention of files which were changed, updated, then > changed has always bothered me). However, I'm not sure how we can get > the diff machinery to figure this out easily. Getting the knowledge for > the line above requires diffing tree to cache and cache to working > directory. Is there a better way than saving the queue from one diff and > cross-referencing it with the other? I do not think so. I was initially planning to write a new traversal function that walks working tree, index _and_ a tree in parallel, but that would not work well with -M and -C, so I dropped it. - : send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html