Kristian Høgsberg <krh@xxxxxxxxxx> writes: > Signed-off-by: Kristian Høgsberg <krh@xxxxxxxxxx> Huh? -EPARSE_TITLE_STRING [PATCH 1/4] Add a simple option parser for use by builtin-commit.c. [PATCH 2/4] This exports the update() function from builtin-add.c as [PATCH 3/4] Implement git commit as a builtin command. [PATCH 4/4] Move launch_editor() and stripspace() to new file editor.c. Let's step back a bit. The whole series organization is very screwy. Especially I do not think 4/4 should be at the end. Reviewing your old series... * Enable wt-status output to a given FILE pointer. * Enable wt-status to run against non-standard index file. Let's have the above two from the previous series in 'next'. Now the following five that have been in 'pu' are from the older series: * Introduce entry point for launching add--interactive. * Clean up stripspace a bit, use strbuf even more. * Add strbuf_read_file(). * Export rerere() and launch_editor(). * Implement git commit as a builtin command. The changes to stripspace and strbuf_read_file() are unrelated to making the commit command a builtin. I have extended the strbuf topic with these two and merged the result to 'next'. I think the right organization for the "builtin-commit" series should be: * merge strbuf topic in kh/commit topic, in order to get the stripspace updates and strbuf_read_file(); * add--interactive entry point change (respin the one from the old series); * rename update() to add_files_to_cache() and export (respin this [2/4] with a better commit message); * create a separate rerere() function and export (respin part of old series, with proper refactoring); I am not happy with builtin-foo.c calling into something from builtin-bar.c, though. We probably would want to move rerere() and add_files_to_cache() somewhere else. * move launch_editor() and stripspace() to create editor.c (new [4/4]); * add option parser in parse-options.[ch] (new [1/4]); * finally, create builtin-commit that uses the groundwork laid out above (new [3/4]). I ended up doing the above up to the rerere() one myself, but haven't done the rest. I probably would start more aggressively asking the original author to clean up and resubmit from now on. I haven't managed to scrape enough time for myself to code anything meaningful for git recently, and instead spent too much time fixing up other peoples code. - To unsubscribe from this list: 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
