Junio C Hamano wrote: > As the feature itself is primarily designed for scripts that want to > always disable writing of FETCH_HEAD, I can certainly understand a > short-term/sighted view of not wanting to add configuration, though. Yes, I think that since this feature is primarily designed for scripts, an option is more likely to be useful for them than a config setting. An option kicks in when the calling script requests it; a config setting can kick in even when they didn't intend to request it. My opinion would change if we think that we're going to flip the default to --no-write-fetch-head some day, in which case a config setting would be a good way to request a preview of the future. But I don't believe anyone's brought that up as a direction we want to pursue. [...] >> If someone specifies both, then they probably want to say >> "show me what I would write to FETCH_HEAD but don't actually do that" - >> which isn't info that we print anyways, right now. > > Do you mean "don't actually write but show it to standard output > instead" or something? My take is that the behavior that the patch implements for --dry-run --write-fetch-head is correct and what a user would want: it acts *as though* you passed --write-fetch-head (including producing the same console output), without producing mutations that the user might regret (such as updating FETCH_HEAD). Thanks and hope that helps, Jonathan
