git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Jonathan Nieder <jrnieder@gmail.com>
Date
Jan 28, 2011, 17:56 UTC
Message-ID
<20110128175609.GA27118@burratino>
In-Reply-To
<1296233099.12855.14.camel@drew-northup.unet.maine.edu>
Drew Northup wrote:
> 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.
[...]
Show 12 quoted lines
>> --- 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}";
[...]
> 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.

I generally have some sympathy for that point of view (especially given the "because we can" commit message). In this case, can you think of an example where one would type "git merge" without a branchname argument and expect it to do something else?

 - Never used "git merge" before, trying it for the first time.
   In this case, I think merging from upstream is a good behavior,
   relatively consistent with "git pull".
 - In a script trying to do an octopus, in the special case of no
   extra parents.  Rough plumbing equivalent:
	set --
	git merge-recursive HEAD -- HEAD "$@"
	tree=$(git write-tree)
	git fetch . "$@" 2>/dev/null
	git fmt-merge-msg <.git/FETCH_HEAD |
	git commit-tree $tree \
		$(git merge-base --independent HEAD "$@" | sed 's/^/-p ')
   The porcelain "git fetch" is used to populate .git/FETCH_HEAD (the
   fmt-merge-msg manual doesn't explain any other way).  Maybe it
   would be better to write the log message by hand.  In any case, the
   porcelain "git fetch" defeats us --- "git fetch ." means to fetch
   the default refspec instead of no branches.
   It might be nice to have a better way to format merge messages
   (like "git fmt-merge-msg --refspec "$@"?) so we can give better
   advice to the author of the script that uses "git merge $@" and
   already breaks in the no-heads case.
 - Started typing a "git merge" command with lots of switches and
   forgot to type the branch name.  It might help to print some output
   'defaulting to branch <foo>' so the operator can notice the
   mistake.

Other nits: documentation? tests? The rest of cmd_merge does not rely on argv[argc] being NULL, but it might make sense to set argv[1] to NULL anyway for futureproofing.

Thanks. Jonathan

Previous: Felipe ContrerasNext: Felipe Contreras
Message 4 of 9 in “merge: default to @{upstream}”
  1. merge: default to @{upstream}Felipe Contreras, Jan 28, 2011
  2. Drew NorthupJan 28, 2011
  3. Felipe ContrerasJan 28, 2011
  4. Jonathan NiederJan 28, 2011
  5. Felipe ContrerasJan 28, 2011
  6. Jonathan NiederJan 30, 2011
  7. Bert WesargJan 28, 2011
  8. Martin von ZweigbergkJan 28, 2011
  9. Miles BaderJan 31, 2011

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.