Re: [PATCH/RFC/GSOC] make git-pull a builtin

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Mar 23, 2015, 09:07 UTC
Message-ID: <4f9cfb776b8a1418ba1b3bc07b10f577@www.dscho.org>
In-Reply-To: <CACRoPnT04p-6o2u984a21RvHkk6CqpZWRyafg=T+WAPOD3hiTg@mail.gmail.com>

Hi Paul,

On 2015-03-22 18:39, Paul Tan wrote:

> The code coverage tools can help here as well. The kcov output clearly
> shows which options of git-pull are currently not being tested. But
> yes, I agree that the test suite shouldn't be relied too much on
> compared to code inspection and review.

Fully agree.

Show 16 quoted lines

> On another important topic, though, along with git-pull.sh, I'm
> looking for another script to convert in parallel with git-pull.sh so
> that there will be no blocks due to patch review. Generally, I think
> rewriting scripts that are called frequently by users, or spawn a lot
> of processes due to loops, would be most desirable because the runtime
> gains would be much higher. A quick review of the scripts shows that
> git-am.sh, git-rebase--interactive.sh and git-quiltimport.sh have
> pretty heavy loops with lots of process spawning that grows with
> input.
> 
> I'm currently leaning with git-am because not only is it a frequently
> used command, git-rebase--am.sh (for non-interactive rebase) calls it
> as well. In fact, quick tests show that it takes up 98% of
> git-rebase's execution time on Windows, so if git-am's performance
> improves it would be a huge win on many fronts. git-am's code also
> seems to be manageable for a 3-month project.

Yeah, `git am` is definitely a good pick.

Thanks! Johannes