Stefan Beller <sbeller@xxxxxxxxxx> writes:
> Signed-off-by: Stefan Beller <sbeller@xxxxxxxxxx>
> ---
>
> So I was trying to understand how to implement "git add .gitmodules" as
> I intend to rewrite git submodules in C.
A request and a suggestion.
- Please keep Jens and Heiko in the loop and pick their brains ;-)
- It may not be the best use of your time to attempt rewriting the
whole of "git submodule" in C in a single pass (which is the
impression I am getting from seeing you say "git add
.gitmodules").
The largest pain point a rewrite in C would solve is that "git
submodule init" and "update" have to go sequencially even though
(1) there is no inherent reason for cloning and fetching of
different submodules to happen in some order;
(2) there is no inherent reason for a failure to clone or fetch
of one submodule to abort the entire session without cloning
or fetching other submodules; and
(3) the operation in each submodule takes human-scale time and
the users would benefit greatly by parallel operations.
One approach that may be beneficial would be to introduce "git
submodule--helper" written in C to have selected primitives used
in "git submodule" script to speed them up. Perhaps the first
subcommand would be "
$ git submodule--helper foreach-parallel --cmd=$cmd $args...
where it takes the arguments currently fed to module_list as
$args... and runs $cmd in parallel. The initial implementation
of "git submodule update" then would replace the expensive and
sequencial
module_list "$@" | {
...
while read mode sha1 stage sm_path
do
...
done
}
loop with a call to the foreach-parallel subcommand.
The end-user scripts that currently use "git submodule foreach"
may or may not depend on the sequencial nature of the current
implementation, so adding "git submodule foreach-parallel" may be
a good way to expose this as a new "do it in parallel" feature.
Once you have a solid infrastructure to implement the helper
subcommand "foreach-parallel" (I'd expect the interface inside C
into that function would be to give it a worker function with the
data for the function to consume, and the above --cmd=$cmd form
would use a worker function that essentially does run_command();
the spawn(2)ing and wait(2)ing would be done on the more generic
API side), you can rewrite the $cmd part in C little by little,
and eventually you would get a full C implemention while keeping
everything working and retaining debuggability during the course
of development.
Thanks.
--
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