Paul Tan <pyokagan@xxxxxxxxx> writes:
> This series rewrites git-pull.sh into a C builtin, thus improving its
> performance and portability. It is part of my GSoC project to rewrite git-pull
> and git-am into builtins[2].
Earlier you were worried about 'git pull' being used in many tests
for the purpose of testing other parts of the system and not testing
'pull' itself. For a program as complex as 'git pull', you may want
to take the 'competing implementations' approach.
(1) write an empty cmd_pull() that relaunches "git pull" scripted
porcelain from the $GIT_EXEC_PATH with given parameters, and
wire all the necessary bits to git.c.
(2) enhance cmd_pull() a bit by bit, but keep something like this
if (getenv(GIT_USE_BUILTIN_PULL)) {
/* original run_command("git-pull.sh") code */
exit $?
}
... your "C" version ...
(3) add "GIT_USE_BUILTIN_PULL=Yes; export GIT_USE_BUILTIN_PULL" at
the beginning of "t55??" test scripts (but not others that rely
on working pull and that are not interested in catching bugs in
pull).
(4) once cmd_pull() becomes fully operational, drop (3) and also the
conditional one you added in (2), and retire the environment
variable. Retire the git-pull.sh script to contrib/examples/
boneyard.
That way, you will always have a reference you can use throughout
the development.
Just a suggestion, not a requirement.
--
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