{"thread":{"id":"17371","subject":"[PATCH] Allow format-patch to create patches for merges","startedAt":"2009-01-26T14:04:10Z","lastAt":"2009-01-26T21:46:42Z","messageCount":6,"participants":["Nathan W. Panike","Johannes Schindelin","Junio C Hamano","Jeff King"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"101985","messageId":"1232978650-7008-1-git-send-email-nathan.panike@gmail.com","threadId":"17371","inReplyTo":null,"subject":"[PATCH] Allow format-patch to create patches for merges","fromName":"Nathan W. Panike","fromEmail":"nathan.panike@gmail.com","sentAt":"2009-01-26T14:04:10Z","receivedAt":"2009-01-26T14:04:10Z","isPatch":true,"sender":{"key":"nathan.panike@gmail.com","avatar":"https://avatars.githubusercontent.com/u/389447?v=4"},"body":"The behavior for git format-patch is to ignore merge commits, producing an\nempty patch. The code does not allow the user to change this behavior. This\npatch changes that behavior by allowing the user to specify -c or -m at the\ncommand line to produce a patch for a merge commit.\n---\nHi:\n\nI am sure there are good reasons for the current behavior of format-patch, but\nit seems to me that if the user explicitly wants to produce a patch for a merge\ncommit, he should be allowed to do so. If merge_commit represents a merge,\nthen this patch allows the user to issue the command\n\ngit format-patch -m -1 $merge_commit \n\nor \n\ngit format-patch -c -1 $merge_commit\n\nand actually produce a patch. The current behavior is that neither command\nwill produce a patch. With or without the patch applied, the command\n\ngit format-patch -1 $merge_commit\n\ndoes not produce a patch when merge_commit is a merge. Thus the patch does not\nchange the default behavior of ignoring merges, at least by the limited testing\nI have done. \n\nThanks for your consideration.\n\nNathan Panike\n\n builtin-log.c | 4 ----\n 1 files changed, 0 insertions(+), 4 deletions(-)\n\ndiff --git a/builtin-log.c b/builtin-log.c\nindex 2ae39af..ea4729d 100644\n--- a/builtin-log.c\n+++ b/builtin-log.c\n@@ -994,10 +994,6 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)\n \t\t\tcontinue;\n \t\t}\n \n-\t\t/* ignore merges */\n-\t\tif (commit->parents && commit->parents->next)\n-\t\t\tcontinue;\n-\n \t\tif (ignore_if_in_upstream &&\n \t\t\t\thas_commit_patch_id(commit, &ids))\n \t\t\tcontinue;\n-- \n1.6.1.1.GIT\n"},{"id":"101993","messageId":"alpine.DEB.1.00.0901261604420.25749@intel-tinevez-2-302","threadId":"17371","inReplyTo":"1232978650-7008-1-git-send-email-nathan.panike@gmail.com","subject":"Re: [PATCH] Allow format-patch to create patches for merges","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-01-26T15:36:47Z","receivedAt":"2009-01-26T15:36:47Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 26 Jan 2009, Nathan W. Panike wrote:\n\n> The behavior for git format-patch is to ignore merge commits, producing \n> an empty patch. The code does not allow the user to change this \n> behavior. This patch changes that behavior by allowing the user to \n> specify -c or -m at the command line to produce a patch for a merge \n> commit.\n\nYour patch is almost perfect, except that you\n\n- lack an explanation when this makes sense (format-patch is commonly used \n for mail-based patch queues, and only -m 1 would make sense there, and \n only if you run format-patch with --first-parent),\n\n- did not add your Sign-off :-)\n\nCiao,\nDscho\n"},{"id":"101999","messageId":"d77df1110901260827j2200fe41oe1b84c387d88aba@mail.gmail.com","threadId":"17371","inReplyTo":"alpine.DEB.1.00.0901261604420.25749@intel-tinevez-2-302","subject":"Re: [PATCH] Allow format-patch to create patches for merges","fromName":"Nathan W. Panike","fromEmail":"nathan.panike@gmail.com","sentAt":"2009-01-26T16:27:18Z","receivedAt":"2009-01-26T16:27:18Z","isPatch":true,"sender":{"key":"nathan.panike@gmail.com","avatar":"https://avatars.githubusercontent.com/u/389447?v=4"},"body":"On Mon, Jan 26, 2009 at 9:36 AM, Johannes Schindelin\n wrote:\n> Hi,\n>\n> On Mon, 26 Jan 2009, Nathan W. Panike wrote:\n>\n>> The behavior for git format-patch is to ignore merge commits, producing\n>> an empty patch. The code does not allow the user to change this\n>> behavior. This patch changes that behavior by allowing the user to\n>> specify -c or -m at the command line to produce a patch for a merge\n>> commit.\n>\n> Your patch is almost perfect, except that you\n>\n> - lack an explanation when this makes sense (format-patch is commonly used\n> for mail-based patch queues, and only -m 1 would make sense there, and\n> only if you run format-patch with --first-parent),\n>\nI think I have an unusual workflow where my patch makes sense,\nalthough it probably does not for the vast majority of git users. I\nregularly use 3 machines: S, L, and H. I keep my work synchronized by\nusing git. Normally, I fetch from S to L or to H, depending on which\nmachine I am working on at the moment. I also push from L or H to S.\nI sporadically lose connectivity to S, so I have a hook in the repo on\nS to send a backup email to me on mail server M, which has a more\nreliable connection. This email also serves as a reminder when I\nhave moved from one machine to another with a degree of latency; and I\ncan use the mail queue on M to recreate most of my state, if I cannot\nfetch from S. In this workflow, I would really like git to create a\npatch, even in the merge case, and I think I want to see that it was a\nmerge.\n\nWhat I do not want to see is an empty patch when a non-trivial change\nhas occurred, which is the way it works now.\n\nAlso, I think I must be issuing the wrong command, as when I do\n\ngit format-patch --first-parent --stdout -1 $merge_commit\n\nthere is no data, with or without my patch.\n\n> - did not add your Sign-off :-)\n\nOops. Thanks for the catch.\n\n>\n> Ciao,\n> Dscho\n>\n>\n"},{"id":"102015","messageId":"7v3af57w8x.fsf@gitster.siamese.dyndns.org","threadId":"17371","inReplyTo":"alpine.DEB.1.00.0901261604420.25749@intel-tinevez-2-302","subject":"Re: [PATCH] Allow format-patch to create patches for merges","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-01-26T18:33:34Z","receivedAt":"2009-01-26T18:33:34Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> - lack an explanation when this makes sense (format-patch is commonly used \n> for mail-based patch queues, and only -m 1 would make sense there, and \n> only if you run format-patch with --first-parent),\n\nYou do not necessarily want --first-parent.\n\nSuppose you have this topology\n\n B---D---E\n / /\n M---A---C\n\nwhere M is 'master', and E is 'mine'.\n\nThe format-patch command ignores merges by default because you can get\ndiff for A-M, B-A, C-A, E-D and serialize the resulting history without\nit, and this is often sufficient. When D merges with a conflict, or D is\nan evil merge, however, you will not be able to reproduce how D looked\nlike on the receiving end. Your --first-parent would instead format the\nlog message for A B D E with patch text of A-M, B-A, D-B and E-D.\n\nBut as a recipient of such a patch series, I'd much prefer to see the\npatch text and the log message of B and C themselves. I'd either apply\nthem on top of A serially, or apply them on top of A to recreate the\nforked history the sender had and merge, to arrive at the state the sender\nhad at D either way, resolving a potential conflict (either when applying\nC on top of B, or when merging between B and C), and apply E on top.\n\nGetting a first parent diff that says \"I merged random stuff here at D and\nhere is the difference D-B\", is much less useful and throws us back to\ndark ages of CVS/SVN merges, especially because C could be a long\nmulti-patch sequence.\n\nI am not happy about Nathan's output. I think \"-m\" output is a wrong\nthing to use in that it just lets D-B and D-C patches in the same output\nfile, without marking that it is something you should not be applying as\npart of the series blindly. The patch is \"If you reproduced my B and C\nwith the patches so far, here is a hint to help you recreate the merged\nstate D\", and care must be taken to make sure both the tool and the user\nnotice the situation. \"git am\", after you have applied B and then C, will\nnotice that the patches for D does not apply anyway, but the message\nshould tell the recipient that it is _expected_ not to apply to avoid\nconfusion. One possible solution might be to always show --cc patch in\nsuch a case, which (1) won't apply with patch nor git-am, and (2) will be\nclear it is not a patch by having more than two @@ signs on each hunk\nheader.\n\nIf you really want to generate a patch for a merge commit (e.g. D in the\nabove picture), what you may want is \"here is a fix-up you need to apply\non top of the result of naturally merging B and C to arrive at D\". It\ncould be empty if the merge is conflict-free and there is no evil amend.\n\nHere is a food-for-thought sample history for interested parties to\nexperiment on.\n\n"},{"id":"102044","messageId":"20090126204543.GF27604@coredump.intra.peff.net","threadId":"17371","inReplyTo":"d77df1110901260827j2200fe41oe1b84c387d88aba@mail.gmail.com","subject":"Re: [PATCH] Allow format-patch to create patches for merges","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-01-26T20:45:43Z","receivedAt":"2009-01-26T20:45:43Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Jan 26, 2009 at 10:27:18AM -0600, Nathan W. Panike wrote:\n\n> I think I have an unusual workflow where my patch makes sense,\n> although it probably does not for the vast majority of git users. I\n> regularly use 3 machines: S, L, and H. I keep my work synchronized by\n> using git. Normally, I fetch from S to L or to H, depending on which\n> machine I am working on at the moment. I also push from L or H to S.\n> I sporadically lose connectivity to S, so I have a hook in the repo on\n> S to send a backup email to me on mail server M, which has a more\n> reliable connection. This email also serves as a reminder when I\n\nHave you considered sending a bundle instead of a patch in the backup\nemail? That is the more exact equivalent of a push (i.e., it preserves\nyour actual commits, sha1 and all).\n\n-Peff\n"},{"id":"102062","messageId":"d77df1110901261346k7951809cv240ccddc22bf4884@mail.gmail.com","threadId":"17371","inReplyTo":"20090126204543.GF27604@coredump.intra.peff.net","subject":"Re: [PATCH] Allow format-patch to create patches for merges","fromName":"Nathan W. Panike","fromEmail":"nathan.panike@gmail.com","sentAt":"2009-01-26T21:46:42Z","receivedAt":"2009-01-26T21:46:42Z","isPatch":true,"sender":{"key":"nathan.panike@gmail.com","avatar":"https://avatars.githubusercontent.com/u/389447?v=4"},"body":"I have not used the bundle stuff, but yes, it seems to be a better fit\nfor what I am trying to do.\n\nThanks,\n\nNathan Panike\n\nOn Mon, Jan 26, 2009 at 2:45 PM, Jeff King wrote:\n> On Mon, Jan 26, 2009 at 10:27:18AM -0600, Nathan W. Panike wrote:\n>\n>> I think I have an unusual workflow where my patch makes sense,\n>> although it probably does not for the vast majority of git users. I\n>> regularly use 3 machines: S, L, and H. I keep my work synchronized by\n>> using git. Normally, I fetch from S to L or to H, depending on which\n>> machine I am working on at the moment. I also push from L or H to S.\n>> I sporadically lose connectivity to S, so I have a hook in the repo on\n>> S to send a backup email to me on mail server M, which has a more\n>> reliable connection. This email also serves as a reminder when I\n>\n> Have you considered sending a bundle instead of a patch in the backup\n> email? That is the more exact equivalent of a push (i.e., it preserves\n> your actual commits, sha1 and all).\n>\n> -Peff\n>\n"}]}