Thanks for this PR, @tiennou. Could you please add an entry to our changelog so that people will (hopefully) notice the change?

There are a couple of places that take a checkout options structure and then upgrade the defaults to SAFE. This was an annoying workaround to avoid having to make consumers of those functions deal with this already esoteric checkout issue. For example, rebase upgrades the checkout options if neither SAFE nor FORCE is specified. (Ugh.)

Those can (and should) go away now -- which would allow consumers to actually provide a checkout strategy that does a dry run. At the moment, there's no way for them to do that.

That doesn't have to be part of this PR, but if not, please open an issue and assign it to me to investigate.

Fixed up the CHANGELOG, the documentation (heh), as well as the uses I found where the fix was clear.

I've left this (called from there) because I don't think it's related, but someone with a more complete grasp of the merge code should take a look. My understanding was "we're doing weird stuff with the indexwriter and not-writing-indexes so we're stashing the user-given strategy somewhere, munging the options one, and then use both in different codepaths".

I think the untouched region is fine:

	unsigned int checkout_strategy;
	...
	checkout_strategy = given_checkout_opts ?
		given_checkout_opts->checkout_strategy : GIT_CHECKOUT_SAFE;
	...
	if ((error = merge_normalize_checkout_opts(&checkout_opts, repo,
			given_checkout_opts, checkout_strategy,
			base, our_head, their_heads, their_heads_len)) < 0 ||
		(error = git_checkout_index(repo, index, &checkout_opts)) < 0)
		goto done;

So it will use the user-supplied checkout strategy and fall back to GIT_CHECKOUT_SAFE, which is exactly what we want to do here.

I'm fine with the PR. Will not approve it though as I'm not as familiar with the code as @ethomson

Awesome, thanks @tiennou!