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. > 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 -- 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