On Mon, Jan 31, 2011 at 09:06:33AM -0800, Junio C Hamano wrote: > 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. I am not sure these things are not already broken. "git merge" without arguments right now is not a no-op. It is an error that spews usage to stderr and exits 129. Yes, there can be scripts which stupidly do not bother to see if the merge succeeded, but I'm not sure how much we should care about such poorly written junk. > 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 nit: upon reading the name of the variable, I assumed it would be "the default upstream to merge". Perhaps "merge.defaultToUpstream" is a more descriptive name? > 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. Don't we already issue a giant warning when "git merge" is run without a commit, namely: usage: git merge [options] <remote>... ... etc ... ? If people are already not paying attention to that (either because they are throwing away stderr and exit code indiscriminately, or because the no-arguments case is a simply an obscure corner that their script doesn't usually exercise), why would they pay attention to a new warning? > In 1.8.0, flip the default for merge.defaultUpstream to true. Other than that, I think the proposal and migration plan are fine. -Peff -- 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