Hi Paul, On Wed, 16 Mar 2016, Paul Tan wrote:
> On Wed, Mar 16, 2016 at 3:58 PM, Johannes Schindelin > <johannes.schinde...@gmx.de> wrote: > > > > On Sat, 12 Mar 2016, Paul Tan wrote: > > > >> diff --git a/t/perf/p3404-rebase-interactive.sh > >> b/t/perf/p3404-rebase-interactive.sh > >> new file mode 100755 > >> index 0000000..aaca105 > >> --- /dev/null > >> +++ b/t/perf/p3404-rebase-interactive.sh > >> @@ -0,0 +1,26 @@ > >> > >> [...] > >> > >> +test_perf 'rebase -i --onto master^' ' > >> + git checkout perf-topic-branch && > >> + git reset --hard perf-topic-branch-initial && > >> + GIT_SEQUENCE_EDITOR=: git rebase -i --onto master^ master > >> +' > > > > This measures the performance of checkout && reset && rebase -i. Maybe we > > should only test rebase -i? > > test_perf runs the same script multiple times, so we need to reset > --hard at least to undo the changes of the rebase. > > I think we can remove the reset if we use rebase -f and rebase onto > the same base, but -f was not implemented in this patch series. Hrm. rebase -f just makes the reset an implicit part of the rebase, so it seems we cannot perf *just* the rebase. We are stuck with perf'ing also the reset. Sad. > > Also, I would strongly recommend an extra test_commit after reset; > > Otherwise you would only test the logic that verifies that it can simply > > fast-forward instead of cherry-picking. > > Or, we could use the -f flag, I think. Yeah, we can do that, too. Ciao, Dscho -- 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
