Re: [PATCH] merge: default to @{upstream}

[Drew Northup <drew.northup@maine.edu>]

On Fri, 2011-01-28 at 18:17 +0200, Felipe Contreras wrote:
> So 'git merge' is 'git merge @{upstream}' instead of 'git merge -h';
> it's better to do something useful.
> 
> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
> ---
>  builtin/merge.c |    8 +++++---
>  1 files changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/builtin/merge.c b/builtin/merge.c
> index 42fff38..f23d669 100644
> --- a/builtin/merge.c
> +++ b/builtin/merge.c
> @@ -983,9 +983,11 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
>  	if (!allow_fast_forward && fast_forward_only)
>  		die("You cannot combine --no-ff with --ff-only.");
>  
> -	if (!argc)
> -		usage_with_options(builtin_merge_usage,
> -			builtin_merge_options);
> +	if (!argc) {
> +		/* argv[argc] should be NULL, so we can hijack it */
> +		argv[0] = "@{u}";
> +		argc = 1;
> +	}
>  
>  	/*
>  	 * This could be traditional "merge <msg> HEAD <commit>..."  and

Honestly, I'd prefer that this NOT be merged in. When I mess up the
command line I am typing I don't want some sort of hidden magic to kick
in--I want it to tell me that I did something stupid by printing out the
help message. This is standard to a large number of commands that by
default expect a certain number of operands and I don't see any good
reason why git merge should be any different.

-- 
-Drew Northup
________________________________________________
"As opposed to vegetable or mineral error?"
-John Pescatore, SANS NewsBites Vol. 12 Num. 59