From: Drew Northup Date: Fri, 28 Jan 2011 16:44:59 GMT Subject: Re: [PATCH] merge: default to @{upstream} Message-ID: <1296233099.12855.14.camel@drew-northup.unet.maine.edu> In-Reply-To: <1296231457-18780-1-git-send-email-felipe.contreras@gmail.com> 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 > --- > 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 HEAD ..." 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