Proposal: Currently "git merge" without saying what to merge is a no-op, and succeeds silently. As many downstream developers (that are by definition more numerous than people who do not have "upstream") run merge from the configured upstream of the current branch most of the time, it would make it more convenient for them to change the default to merge from the upstream of the current branch. Running "git merge" without argument, when there is no upstream defined for the current branch, will be an error. Risks: Existing scripts may prepare what to merge in an array (e.g. in Bourne, accumulating them in "$@" by repeatedly doing 'set "$@" "$newbranch"') and call 'git merge "$@"', relying on the current behaviour that zero argument means no-op. Such scripts will be broken by this change. Driving "git merge" with xargs without --no-run-if-empty (not POSIX), feeding the branches to merge in an Octopus, will be broken the same way. Migration plan: Add merge.defaultUpstream configuration variable, which defaults to false when unconfigured. Change "git merge" so that when this configuration is set and the command is run without the commit to merge to use the configured upstream of the current branch (or error out if there isn't one). Merge this change in the next 1.7.x series. One release before 1.8.0, issue a warning when "git merge" is run without the commit to merge and this configuration variable is not explicitly set either way, and notify the user of upcoming incompatibility. In 1.8.0, flip the default for merge.defaultUpstream to true. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html