Fix/vik/speed up oe test

[VikParuchuri]

Speed up open ended test that is timing out.

Per @cpennington and @gwprice this was okay to merge if two commits were folded together. Folding done, going to merge after jenkins validates.

[gwprice]

You should rebase instead of merging master in.

[cpennington]

@VikParuchuri the commits aren't merged together. You need to run git rebase -i origin/master, and then mark the second commit as fixup, and remove the merge entirely.

[gwprice]

Also, avoid relative references (like "this error") in commit messages.

[VikParuchuri]

@cpennington There were three, and I merged two of them together (i think). I used squash. I will merge the remaining two together to just have it all as one commit.

[VikParuchuri]

All set now.

[VikParuchuri]

@gwprice How do you avoid having to do git push -f after rebasing? That's the primary reason I tend to use merge instead of rebase.

[gwprice]

You don't avoid it; force pushing is fine for branches that nobody else is using.

[gwprice]

👍

[VikParuchuri]

I've seen issues where people have force pushed the wrong thing that took a lot of time to resolve. I wonder what the relative time taken/cost fixing those mistakes vs. using merge instead of rebase is.

[cpennington]

The only issues I've run into w/ force pushing the wrong thing are 1) they
have global pushes turned on, so they force push more than the one branch
they are trying to and 2) they are trying to do something fancy w/ force
push (like push one branch to another). I think for this simple case, the
benefits of cleaner history outweigh the costs.

On Fri, May 31, 2013 at 11:38 AM, VikParuchuri notifications@github.comwrote:

I've seen issues where people have force pushed the wrong thing that took
a lot of time to resolve. I wonder what the relative time taken/cost fixing
those mistakes vs. using merge instead of rebase is.

—
Reply to this email directly or view it on GitHubhttps://github.com/edx/pull/3#issuecomment-18752740
.