{"thread":{"id":"26358","subject":"[PATCH] merge: default to @{upstream}","startedAt":"2011-01-28T16:17:37Z","lastAt":"2011-01-31T01:55:49Z","messageCount":9,"participants":["Felipe Contreras","Drew Northup","Jonathan Nieder","Bert Wesarg","Martin von Zweigbergk","Miles Bader"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"159990","messageId":"1296231457-18780-1-git-send-email-felipe.contreras@gmail.com","threadId":"26358","inReplyTo":null,"subject":"[PATCH] merge: default to @{upstream}","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2011-01-28T16:17:37Z","receivedAt":"2011-01-28T16:17:37Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"So 'git merge' is 'git merge @{upstream}' instead of 'git merge -h';\nit's better to do something useful.\n\nSigned-off-by: Felipe Contreras <felipe.contreras@gmail.com>\n---\n builtin/merge.c |    8 +++++---\n 1 files changed, 5 insertions(+), 3 deletions(-)\n\ndiff --git a/builtin/merge.c b/builtin/merge.c\nindex 42fff38..f23d669 100644\n--- a/builtin/merge.c\n+++ b/builtin/merge.c\n@@ -983,9 +983,11 @@ int cmd_merge(int argc, const char **argv, const char *prefix)\n \tif (!allow_fast_forward && fast_forward_only)\n \t\tdie(\"You cannot combine --no-ff with --ff-only.\");\n \n-\tif (!argc)\n-\t\tusage_with_options(builtin_merge_usage,\n-\t\t\tbuiltin_merge_options);\n+\tif (!argc) {\n+\t\t/* argv[argc] should be NULL, so we can hijack it */\n+\t\targv[0] = \"@{u}\";\n+\t\targc = 1;\n+\t}\n \n \t/*\n \t * This could be traditional \"merge <msg> HEAD <commit>...\"  and\n-- \n1.7.4.rc3\n"},{"id":"159993","messageId":"1296233099.12855.14.camel@drew-northup.unet.maine.edu","threadId":"26358","inReplyTo":"1296231457-18780-1-git-send-email-felipe.contreras@gmail.com","subject":"Re: [PATCH] merge: default to @{upstream}","fromName":"Drew Northup","fromEmail":"drew.northup@maine.edu","sentAt":"2011-01-28T16:44:59Z","receivedAt":"2011-01-28T16:44:59Z","isPatch":true,"sender":{"key":"drew.northup@maine.edu","avatar":"https://avatars.githubusercontent.com/u/18331571?v=4"},"body":"\nOn Fri, 2011-01-28 at 18:17 +0200, Felipe Contreras wrote:\n> So 'git merge' is 'git merge @{upstream}' instead of 'git merge -h';\n> it's better to do something useful.\n> \n> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>\n> ---\n>  builtin/merge.c |    8 +++++---\n>  1 files changed, 5 insertions(+), 3 deletions(-)\n> \n> diff --git a/builtin/merge.c b/builtin/merge.c\n> index 42fff38..f23d669 100644\n> --- a/builtin/merge.c\n> +++ b/builtin/merge.c\n> @@ -983,9 +983,11 @@ int cmd_merge(int argc, const char **argv, const char *prefix)\n>  \tif (!allow_fast_forward && fast_forward_only)\n>  \t\tdie(\"You cannot combine --no-ff with --ff-only.\");\n>  \n> -\tif (!argc)\n> -\t\tusage_with_options(builtin_merge_usage,\n> -\t\t\tbuiltin_merge_options);\n> +\tif (!argc) {\n> +\t\t/* argv[argc] should be NULL, so we can hijack it */\n> +\t\targv[0] = \"@{u}\";\n> +\t\targc = 1;\n> +\t}\n>  \n>  \t/*\n>  \t * This could be traditional \"merge <msg> HEAD <commit>...\"  and\n\nHonestly, I'd prefer that this NOT be merged in. When I mess up the\ncommand line I am typing I don't want some sort of hidden magic to kick\nin--I want it to tell me that I did something stupid by printing out the\nhelp message. This is standard to a large number of commands that by\ndefault expect a certain number of operands and I don't see any good\nreason why git merge should be any different.\n\n-- \n-Drew Northup\n________________________________________________\n\"As opposed to vegetable or mineral error?\"\n-John Pescatore, SANS NewsBites Vol. 12 Num. 59\n"},{"id":"159996","messageId":"AANLkTikToBdcqPRx3Gu53r9vS6mwhoi1DS4GV63nOcxH@mail.gmail.com","threadId":"26358","inReplyTo":"1296233099.12855.14.camel@drew-northup.unet.maine.edu","subject":"Re: [PATCH] merge: default to @{upstream}","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2011-01-28T17:53:41Z","receivedAt":"2011-01-28T17:53:41Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Fri, Jan 28, 2011 at 6:44 PM, Drew Northup <drew.northup@maine.edu> wrote:\n> Honestly, I'd prefer that this NOT be merged in. When I mess up the\n> command line I am typing I don't want some sort of hidden magic to kick\n> in--I want it to tell me that I did something stupid by printing out the\n> help message. This is standard to a large number of commands that by\n> default expect a certain number of operands and I don't see any good\n> reason why git merge should be any different.\n\ngit checkout (defaults to HEAD)\ngit diff (defaults to HEAD)\ngit fetch (defaults to origin)\ngit format-patch (defaults to HEAD)\ngit log (defaults to HEAD)\ngit pull (defaults to origin)\ngit show (defaults to HEAD)\n\nHow is this different from 'git pull'? If you are not sure about the\n'git merge' command, then type 'git help merge' instead. Just like if\nyou are not sure about the 'git pull' command. If you type any of\nthese two, a merge would happen, and you can revert it easily with\n'git reset --hard HEAD^'.\n\n-- \nFelipe Contreras\n"},{"id":"159997","messageId":"20110128175609.GA27118@burratino","threadId":"26358","inReplyTo":"1296233099.12855.14.camel@drew-northup.unet.maine.edu","subject":"Re: [PATCH] merge: default to @{upstream}","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2011-01-28T17:56:10Z","receivedAt":"2011-01-28T17:56:10Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Drew Northup wrote:\n> On Fri, 2011-01-28 at 18:17 +0200, Felipe Contreras wrote:\n\n>> So 'git merge' is 'git merge @{upstream}' instead of 'git merge -h';\n>> it's better to do something useful.\n[...]\n>> --- a/builtin/merge.c\n>> +++ b/builtin/merge.c\n>> @@ -983,9 +983,11 @@ int cmd_merge(int argc, const char **argv, const char *prefix)\n>>  \tif (!allow_fast_forward && fast_forward_only)\n>>  \t\tdie(\"You cannot combine --no-ff with --ff-only.\");\n>>  \n>> -\tif (!argc)\n>> -\t\tusage_with_options(builtin_merge_usage,\n>> -\t\t\tbuiltin_merge_options);\n>> +\tif (!argc) {\n>> +\t\t/* argv[argc] should be NULL, so we can hijack it */\n>> +\t\targv[0] = \"@{u}\";\n[...]\n> Honestly, I'd prefer that this NOT be merged in. When I mess up the\n> command line I am typing I don't want some sort of hidden magic to kick\n> in--I want it to tell me that I did something stupid by printing out the\n> help message.\n\nI generally have some sympathy for that point of view (especially\ngiven the \"because we can\" commit message).  In this case, can you\nthink of an example where one would type \"git merge\" without a\nbranchname argument and expect it to do something else?\n\n - Never used \"git merge\" before, trying it for the first time.\n   In this case, I think merging from upstream is a good behavior,\n   relatively consistent with \"git pull\".\n\n - In a script trying to do an octopus, in the special case of no\n   extra parents.  Rough plumbing equivalent:\n\n\tset --\n\tgit merge-recursive HEAD -- HEAD \"$@\"\n\ttree=$(git write-tree)\n\tgit fetch . \"$@\" 2>/dev/null\n\tgit fmt-merge-msg <.git/FETCH_HEAD |\n\tgit commit-tree $tree \\\n\t\t$(git merge-base --independent HEAD \"$@\" | sed 's/^/-p ')\n\n   The porcelain \"git fetch\" is used to populate .git/FETCH_HEAD (the\n   fmt-merge-msg manual doesn't explain any other way).  Maybe it\n   would be better to write the log message by hand.  In any case, the\n   porcelain \"git fetch\" defeats us --- \"git fetch .\" means to fetch\n   the default refspec instead of no branches.\n\n   It might be nice to have a better way to format merge messages\n   (like \"git fmt-merge-msg --refspec \"$@\"?) so we can give better\n   advice to the author of the script that uses \"git merge $@\" and\n   already breaks in the no-heads case.\n\n - Started typing a \"git merge\" command with lots of switches and\n   forgot to type the branch name.  It might help to print some output\n   'defaulting to branch <foo>' so the operator can notice the\n   mistake.\n\nOther nits: documentation?  tests?  The rest of cmd_merge does not\nrely on argv[argc] being NULL, but it might make sense to set argv[1]\nto NULL anyway for futureproofing.\n\nThanks.\nJonathan\n"},{"id":"160000","messageId":"AANLkTi=iMJv+Jtj8YdYhQ_sxu+jBht5YqvSnkS2LUerz@mail.gmail.com","threadId":"26358","inReplyTo":"20110128175609.GA27118@burratino","subject":"Re: [PATCH] merge: default to @{upstream}","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2011-01-28T18:46:15Z","receivedAt":"2011-01-28T18:46:15Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Fri, Jan 28, 2011 at 7:56 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:\n> Other nits: documentation?  tests?  The rest of cmd_merge does not\n> rely on argv[argc] being NULL, but it might make sense to set argv[1]\n> to NULL anyway for futureproofing.\n\nSure, I need to add documentation and tests. I should probably have\nsent this as 'RFC'.\n\nAnyway, I don't think we can set argv[1] to NULL, because it's\npossible that this is \"char *argv[1]\", so that would crash. The only\nthing the standard ensures, is that the last one would be NULL, so\nargv[argc] = NULL, and therefore we can override it, as long as the\nrest of the code checks for argc instead of NULL, which AFAIK in the\nwhole git code it is the case, and certainly in builtin_merge.c\nAFAICS.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"160004","messageId":"AANLkTimc92giAAJnzjv5Bq4f853xqEfLrgB=j+iRXPaf@mail.gmail.com","threadId":"26358","inReplyTo":"1296231457-18780-1-git-send-email-felipe.contreras@gmail.com","subject":"Re: [PATCH] merge: default to @{upstream}","fromName":"Bert Wesarg","fromEmail":"bert.wesarg@googlemail.com","sentAt":"2011-01-28T19:53:34Z","receivedAt":"2011-01-28T19:53:34Z","isPatch":true,"sender":{"key":"bert.wesarg@googlemail.com","avatar":"https://avatars.githubusercontent.com/u/111934?v=4"},"body":"On Fri, Jan 28, 2011 at 17:17, Felipe Contreras\n<felipe.contreras@gmail.com> wrote:\n> So 'git merge' is 'git merge @{upstream}' instead of 'git merge -h';\n> it's better to do something useful.\n\nNice idea. Could you have a look into git rebase, I think this could\nbe applied there too.\n\nAnyway, I think some high level sanity check won't harm. Ie. check if\nthere is an upstream configured.\n\nThanks.\nBert\n"},{"id":"160009","messageId":"alpine.DEB.1.10.1101281633580.11103@debian","threadId":"26358","inReplyTo":"AANLkTimc92giAAJnzjv5Bq4f853xqEfLrgB=j+iRXPaf@mail.gmail.com","subject":"Re: [PATCH] merge: default to @{upstream}","fromName":"Martin von Zweigbergk","fromEmail":"martin.von.zweigbergk@gmail.com","sentAt":"2011-01-28T21:41:15Z","receivedAt":"2011-01-28T21:41:15Z","isPatch":true,"sender":{"key":"martinvonz@gmail.com","avatar":"https://avatars.githubusercontent.com/u/891642?v=4"},"body":"On Fri, 28 Jan 2011, Bert Wesarg wrote:\n\n> On Fri, Jan 28, 2011 at 17:17, Felipe Contreras\n> <felipe.contreras@gmail.com> wrote:\n> > So 'git merge' is 'git merge @{upstream}' instead of 'git merge -h';\n> > it's better to do something useful.\n> \n> Nice idea. Could you have a look into git rebase, I think this could\n> be applied there too.\n\nI submitted an RFC patch for that a while ago [1]. I will soon send a\nre-roll of some rebase refactoring patches I have been working on (I\nhave been busy at work and also waiting for 1.7.4 to be finished). I\nwill then send an updated \"default upstream\" patch again on top of the\nrefactoring patches.\n\nAnd thanks for taking care of the merge case, Felipe. I'm still\nstruggling with the part of Git written in C, so I'm glad you took\nthat part.\n\n> \n> Anyway, I think some high level sanity check won't harm. Ie. check if\n> there is an upstream configured.\n\nWill be done in the case of rebase at least (stolen from the\nimplementation in git pull).\n\n\n[1] http://thread.gmane.org/gmane.comp.version-control.git/161382/\n"},{"id":"160070","messageId":"20110130215105.GA11332@burratino","threadId":"26358","inReplyTo":"AANLkTi=iMJv+Jtj8YdYhQ_sxu+jBht5YqvSnkS2LUerz@mail.gmail.com","subject":"Re: [PATCH] merge: default to @{upstream}","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2011-01-30T21:51:05Z","receivedAt":"2011-01-30T21:51:05Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi again,\n\nFelipe Contreras wrote:\n[out of order for convenience]\n\n> Anyway, I don't think we can set argv[1] to NULL, because it's\n> possible that this is \"char *argv[1]\", so that would crash.\n\nThe original argc is at least 1 (to include \"merge\" as argv[0]) before\nthe args are shifted by parse_options_end.  But probably that is too\ntricky to rely on.\n\n> Sure, I need to add documentation and tests. I should probably have\n> sent this as 'RFC'.\n\nNo problem.  Thanks for keeping the topic alive.\n"},{"id":"160080","messageId":"87hbcp25wa.fsf@catnip.gol.com","threadId":"26358","inReplyTo":"1296231457-18780-1-git-send-email-felipe.contreras@gmail.com","subject":"Re: [PATCH] merge: default to @{upstream}","fromName":"Miles Bader","fromEmail":"miles@gnu.org","sentAt":"2011-01-31T01:55:49Z","receivedAt":"2011-01-31T01:55:49Z","isPatch":true,"sender":{"key":"miles@gnu.org","avatar":"https://gravatar.com/avatar/01069b69593af7bff28e2f97afeb3644ae6fe2f5f56cb3a8cf34c5fb8c36efe5?d=mp&s=160"},"body":"Felipe Contreras <felipe.contreras@gmail.com> writes:\n> So 'git merge' is 'git merge @{upstream}' instead of 'git merge -h';\n> it's better to do something useful.\n\nI totally agree -- this would be a good change[*] -- but this suggestion\nhas been made before, and always gets shot down for vaguely silly\nreasons...\n\nI often do \"git fetch; <see what changed upstream>; git pull\".  I think\nthis is probably not a rare pattern, when one is working with other\npeople via a shared upstream.\n\nThe git-pull is obviously slightly risky because another change could\nhave happened after the fetch, but I use that instead of \"git-merge\"\nbecause git-pull's defaults make it very convenient ... and _usually_\nthere's no issue...  If git-merge had proper defaults (as you suggest),\nit would be exactly as convenient as git-pull (and _less_ dangerous), so\nI'd use that instead.\n\n[and, no, saying \"you can add an alias!\" is not a reasonable answer --\ngit should be convenient by default!]\n\n-Miles\n\n-- \nHers, pron. His.\n"}]}