canton7

Git Bisect and Feature Branches

There are people out there who claim that merge-based workflows (that is, workflows which contain non-fast-forward merges) are bad. They claim that git bisect gets confused by merge-based workflows, and instead advocate rebase-based workflows without explicit feature branches.

They're wrong.

Furthermore, the "advantages" of their workflows are in fact disadvantages. Let me show you.

bjacques

package mani;

import static org.hamcrest.Matchers.equalTo;
import static org.hamcrest.Matchers.is;
import static org.junit.Assert.assertThat;
import static org.mockito.Mockito.verify;
import static org.mockito.Mockito.verifyNoMoreInteractions;
import static org.mockito.Mockito.when;
import static org.mockito.MockitoAnnotations.initMocks;

thieux

import org.junit.Test;

public class ArrayCovarianceTest {

	@Test(expected = ArrayStoreException.class)
	public void cat_should_not_be_set_in_dog_list() {
		Animal[] animals = new Dog[1]; // array covariance

		// Java compiler allows the assignment because Dog extends Animal 
		// But the Java runtime throws a "java.lang.ArrayStoreException: Cat"

thieux

Pattern

The input (that feeds a function) can be implemented in 2 ways: controlled by the caller or by the callee.

The outputs (that is provided by a function) can be implemented in 2 ways: exposed to the caller or by message.

Input as parameter

The function's caller controls the input.