Stefan Beller <sbel...@google.com> writes:
> I'd be interested to co-mentor a sh->C conversion.
>
> I think the git-rebase*.sh is a good start.
>
> $ wc -l git-rebase*.sh
> 101 git-rebase--am.sh
> 1296 git-rebase--interactive.sh
> 167 git-rebase--merge.sh
> 636 git-rebase.sh
> 2200 total
>
> So start with rebase--am and rebase--merge to have the same amount
> of lines as git-pull.sh. I did not look at the code, just judging by
> the lines of
> code.
There's a funny exercice there: the git-rebase--$type.sh scripts are not
called as external helpers, but like this:
run_specific_rebase () {
if [ "$interactive_rebase" = implied ]; then
GIT_EDITOR=:
export GIT_EDITOR
autosquash=
fi
. git-rebase--$type
# ...
So, turning these scripts into builtins would first require turning this
". git-rebase--$type" into an actual command call. But nothing
unfeasible.
Anyway, I'm not happy with the current shape of the code since
.-including files within a function already caused us several issues (I
fixed a FreeBSD related bug which triggered another one, so the current
code is a fix for a workaround for a FreeBSD issue ...).
I guess git-rebase--interactive.sh would be a lot for a single GSoC
project, but it can remain a shell-script helper called by a builtin.
Can you add more details to the "Convert scripts to builtins" part of
http://git.github.io/SoC-2016-Ideas/ to reflect this? And make it look
attractive for candidates ;-).
Thanks,
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
