{"thread":{"id":"43109","subject":"Re: git-format-patch little gripe","startedAt":"2006-11-03T09:22:21Z","lastAt":"2006-11-04T01:05:21Z","messageCount":13,"participants":["Jakub Narebski","Linus Torvalds","Luben Tuikov","Carl Worth","Jeff King","Junio C Hamano","Martin Langhoff"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"298467","messageId":"46a038f90611030122reecee87ufac5bbaa910ee933@mail.gmail.com","threadId":"43109","inReplyTo":"376237.14965.qm@web31805.mail.mud.yahoo.com","subject":"Re: git-format-patch little gripe","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2006-11-03T09:22:21Z","receivedAt":"2006-11-03T09:22:21Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 11/3/06, Luben Tuikov wrote:\n> Yep, after more than a year, I simply cannot get used to it...\n> http://marc.theaimsgroup.com/?l=git&m=113259043217761&w=2\n> And as I've seen, other people brought that up too.\n\nHi Luben,\n\nreading the thread, it sounds like you have a couple of shells scripts\nor aliases that do what you want already ;-)\n\nAnd for the scenario you mention, where upstream has taken some of\nyour patches... git-format-patch automatically tries to skip those.\nWorks well for me at least (ducks).\n\n\n"},{"id":"296489","messageId":"511753.217.qm@web31807.mail.mud.yahoo.com","threadId":"43109","inReplyTo":"46a038f90611030122reecee87ufac5bbaa910ee933@mail.gmail.com","subject":"Re: git-format-patch little gripe","fromName":"Luben Tuikov","fromEmail":"ltuikov@yahoo.com","sentAt":"2006-11-03T09:59:18Z","receivedAt":"2006-11-03T09:59:18Z","isPatch":false,"sender":{"key":"ltuikov@yahoo.com","avatar":null},"body":"--- Martin Langhoff wrote:\n> On 11/3/06, Luben Tuikov wrote:\n> > Yep, after more than a year, I simply cannot get used to it...\n> > http://marc.theaimsgroup.com/?l=git&m=113259043217761&w=2\n> > And as I've seen, other people brought that up too.\n> \n> Hi Luben,\n> \n> reading the thread, it sounds like you have a couple of shells scripts\n> or aliases that do what you want already ;-)\n\nYeah, would you know it those scripts got lost somewhere. I now\nknow better -- branch off of git \"next\" and store in USB key. :-)\nSo I generally work off of \"next\" merged to my own branch which includes\nextras I've collected along the way.\n\nBut what wouldn't I give to have\n git-format-_patch_ -o /tmp/ \ngenerate a _single_ patch just as its name implies...\n\n Luben\n\n"},{"id":"297788","messageId":"7vwt6cbwzq.fsf@assigned-by-dhcp.cox.net","threadId":"43109","inReplyTo":"511753.217.qm@web31807.mail.mud.yahoo.com","subject":"Re: git-format-patch little gripe","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-03T11:17:13Z","receivedAt":"2006-11-03T11:17:13Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Luben Tuikov writes:\n\n> But what wouldn't I give to have\n> git-format-_patch_ -o /tmp/ \n> generate a _single_ patch just as its name implies...\n\nIt would have been nicer if you made that argument as a reply to\none of these messages:\n\nhttp://thread.gmane.org/gmane.comp.version-control.git/4266/focus=4279\nhttp://thread.gmane.org/gmane.comp.version-control.git/4843/focus=4843\nhttp://thread.gmane.org/gmane.comp.version-control.git/5440/focus=5446\n\nIt is not an ideology; it is called not breaking existing UI,\nwhich is rather unfortunate, because its UI is not the greatest\nin the world.\n\nBack when it was done, it was not clear that we would have a\nrich set of revision set operations as \"--since=2.weeks\",\n\"from..to\", or \"this...that\" as we have today. Even though we\nhave them now, these set operations do not mesh very well with\nthe patch-id based filtering format-patch needs to do.\n\nIn order to exclude patches that you have as commits that have\nnot been _merged_ into your upstream, but the change they\ncontain have already been _applied_, you would need \"the other\nset\" which is roughly \"rev-list yours..upstream\". Some of your\npatches (i.e. \"rev-list upstream..yours\") may have already\napplied to the upstream but obviously as different commits, and\nyou would fiter them by comparing the patch-ids of them and\nthose from \"the other set\". \n\nUnfortunately, other than the recent addition \"this...that\",\nnone of the revision set operation would give us the \"other set\"\nthat is efficient to use (\"all the commits that is older than 2\nweeks\" is an obvious \"other set\" for \"--since=2.weeks\", but that\nset goes all the way down to the initial commit, which is\nobviously not what we want).\n\nOne thing we talked about but nobody stepped up to code [*1*] is\nto give \"git-format-patch --stdin\" that reads list of commits,\nand runs \"git-diff-tree --pretty --stat --summary -p $commit\".\nWith that, we could do something like:\n\n\tgit rev-list linus..orinoco | git format-patch --stdin\n\nYour \"git-format-patch --single $commit\" is a shorthand for a\ndegenerated special case of that pattern.\n\nYou cannot do patch-id based filtering with this form, but I see\nthat \"single\" is often wanted on the list and #git, and people\nwho want it do not care about patch-id based filtering at all.\nAnd I do not think it is that \"they do not realize how much they\nwould be missing without patch-id filtering\", in this case. So\nthe above command line would probably be Ok.\n\nWith --left-right (in \"pu\"), you could even do something a bit\nfancier like this:\n\n\tgit rev-list --left-right linus...8139cp linus...airo |\n\tgit format-patch --stdin\n\nThe --left-right output option, when used in conjunction with\nthe symmetric difference set operator, prefixes each commit with\n'<' (left) or '>' (right) to indicate which ancestry it belongs\nto (in the above example, the commits only in the branch that\ntracks Linus but not in branches 8139cp or airo are prefixed\nwith '<', and commits on 8139cp or airo branches that have not\nbeen merged in linus are prefixed with '>'). --stdin could use\nthat and take '<' as \"the other set\", i.e. the ones to base\nfiltering of '>' commits on, and output the commits that came\nwith '>' prefix (but subtracting the ones that have equivalent\npatches in the '<' set).\n\n\n[Footnote]\n\n*1* format-patch is primarily the tool for a patch submitter,\nand I did its original version back when I was one. For a long\ntime (an equivalent to \"eternity\" in git timescale back then)\nLinus did not show _any_ interest in it (you can compare the\ndates on the messages I quoted above with the commit date of\n0acfc972), and I suspect one of the reasons is because he was\nthe toplevel maintainer and did not have a need for a tool like\nthat. Now I am the toplevel maintainer here and I haven't felt\nthe need to update it myself for quite some time (\"it works for\nme\"), which is a bit sad.\n\n"},{"id":"295440","messageId":"87y7qsv3l7.wl%cworth@cworth.org","threadId":"43109","inReplyTo":"7vwt6cbwzq.fsf@assigned-by-dhcp.cox.net","subject":"Re: git-format-patch little gripe","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2006-11-03T17:32:04Z","receivedAt":"2006-11-03T17:32:04Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Fri, 03 Nov 2006 03:17:13 -0800, Junio C Hamano wrote:\n>\n> It is not an ideology; it is called not breaking existing UI,\n> which is rather unfortunate, because its UI is not the greatest\n> in the world.\n\nSo maybe we could use some new thing here with cleaner UI. Perhaps:\n\n\tgit export\n\nPaired with a new \"git import\" there would be a much more obvious way\nof working for new users than \"git format-patch\" and \"git am\".\n\nMeanwhile, I don't think export/import is the right place to do the\npatch-id filtering, etc. That seems to work much better in the context\nof something like StackedGit, (which I've started playing with\nrecently and been very impressed with). I'd really like to think about\nsome ways to bring some of the functionality of StackedGit into the\ncore tools. (We've currently got \"git commit --amend\" for example, but\nwhat I often want is \"git goto old-commit; #hack; git commit --amend;\ngit replay\" or whatever, (in Stacked Git speak that is currently \"stg\ngoto old-commit; #hack; stg refresh; stg push --all\").\n\n-Carl\n"},{"id":"293923","messageId":"eifvhc$u59$1@sea.gmane.org","threadId":"43109","inReplyTo":"87y7qsv3l7.wl%cworth@cworth.org","subject":"Re: git-format-patch little gripe","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-11-03T17:51:04Z","receivedAt":"2006-11-03T17:51:04Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Carl Worth wrote:\n\n> (We've currently got \"git commit --amend\" for example, but\n> what I often want is \"git goto old-commit; #hack; git commit --amend;\n> git replay\" or whatever, (in Stacked Git speak that is currently \"stg\n> goto old-commit; #hack; stg refresh; stg push --all\").\n\n\n$ git checkout -b tmp old-commit\n#hack\n$ git commit --amend\n$ git rebase --onto tmp old-commit top\n$ git branch -D tmp\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"294540","messageId":"20061103195253.9244.qmail@web31814.mail.mud.yahoo.com","threadId":"43109","inReplyTo":"7vwt6cbwzq.fsf@assigned-by-dhcp.cox.net","subject":"Re: git-format-patch little gripe","fromName":"Luben Tuikov","fromEmail":"ltuikov@yahoo.com","sentAt":"2006-11-03T19:52:53Z","receivedAt":"2006-11-03T19:52:53Z","isPatch":false,"sender":{"key":"ltuikov@yahoo.com","avatar":null},"body":"--- Junio C Hamano wrote:\n> It would have been nicer if you made that argument as a reply to\n> one of these messages:\n> \n> http://thread.gmane.org/gmane.comp.version-control.git/4266/focus=4279\n> http://thread.gmane.org/gmane.comp.version-control.git/4843/focus=4843\n> http://thread.gmane.org/gmane.comp.version-control.git/5440/focus=5446\n\nI'm amazed at people who can read selectively messages in mailing lists.\nThe amount of messages sometimes is overwhelming.\n\n> It is not an ideology; it is called not breaking existing UI,\n> which is rather unfortunate, because its UI is not the greatest\n> in the world.\n\nYes, it is very unfortunate. It's like the metric system... nobody would\nwant to switch to it if you give them a _choice_... so water is going\nto be freezing at 32 degrees and boiling over at 212.\n\nSo unless someone submits and commits a patch to fix this, and then we\nshelter in the storm, it will never change.\n\n> set\" which is roughly \"rev-list yours..upstream\". Some of your\n> patches (i.e. \"rev-list upstream..yours\") may have already\n\nYeah, that's exactly what I do.\n\n> One thing we talked about but nobody stepped up to code [*1*] is\n> to give \"git-format-patch --stdin\" that reads list of commits,\n> and runs \"git-diff-tree --pretty --stat --summary -p $commit\".\n> With that, we could do something like:\n> \n> \tgit rev-list linus..orinoco | git format-patch --stdin\n\nThat'd be swell to have.\n\n> Your \"git-format-patch --single $commit\" is a shorthand for a\n> degenerated special case of that pattern.\n\nYes, except that I'd have to paste the sha-1 into the terminal\nrather than on the command line. This again proves that the current\ngit-format-patch to mean \"..HEAD\" is horribly broken.\n\n> You cannot do patch-id based filtering with this form, but I see\n> that \"single\" is often wanted on the list and #git, and people\n> who want it do not care about patch-id based filtering at all.\n\nThe reason it is wanted is because it is _intuitive_. This is\nwhat engineers (of different backgrounds) tend to intuitively think\nand assume given git's structure and the nature and meaning of\nwhat an is in git, only to be surprised later when that\nassumption is completely broken by git-format-patch.\n\n\"git-format-patch \" intuitively means \"Show me the commit identified\nby the in a patch format.\"\n\nNow if it had been called \"git-format-patches\" then maybe the argument\nwould've been different.\n\n> And I do not think it is that \"they do not realize how much they\n> would be missing without patch-id filtering\", in this case. So\n> the above command line would probably be Ok.\n\nI do not think they'd be missing _anything_. After all,\n\"git-format-patch ..HEAD\" is also intuitive.\n\n> With --left-right (in \"pu\"), you could even do something a bit\n> fancier like this:\n> \n> \tgit rev-list --left-right linus...8139cp linus...airo |\n> \tgit format-patch --stdin\n> \n> The --left-right output option, when used in conjunction with\n> the symmetric difference set operator, prefixes each commit with\n> '<' (left) or '>' (right) to indicate which ancestry it belongs\n> to (in the above example, the commits only in the branch that\n\nYeah, this is swell too!\n\n> *1* format-patch is primarily the tool for a patch submitter,\n> and I did its original version back when I was one. For a long\n> time (an equivalent to \"eternity\" in git timescale back then)\n> Linus did not show _any_ interest in it (you can compare the\n\nYes, this is sad. There's other places where Linus hasn't shown\nany interest which have been suffering ever since. Someone needs\nto make the decision after all, or at least appoint someone to make\nthe decision (and then blame them ;-) later).\n\n> dates on the messages I quoted above with the commit date of\n> 0acfc972), and I suspect one of the reasons is because he was\n> the toplevel maintainer and did not have a need for a tool like\n> that. Now I am the toplevel maintainer here and I haven't felt\n> the need to update it myself for quite some time (\"it works for\n> me\"), which is a bit sad.\n\nIf I had the clout, I'd change \"git-format-patch \" to\nmean \"git-format-patch ^..\" in a heart-beat, without\neven blinking.\n\nSo what if people find out their tools now generate only _one_ patch\ninstead of N? They'll revisit their scripts and use \"..HEAD\",\n(which says what it means), instead of the completely broken current\nbehavior.\n\nAlso I doubt how many people actually have coded in their scripts\n\"git-format-patch \" to mead by default \"..HEAD\" -- I'd think\nthat maintainers always want to know the \"end point\" and would always\nuse the .. format, instead of presuming where/what their HEAD is.\n\nSorry it's my rant. I know it's not your fault.\n\n Luben\n"},{"id":"298621","messageId":"eiga89$ho$1@sea.gmane.org","threadId":"43109","inReplyTo":"20061103195253.9244.qmail@web31814.mail.mud.yahoo.com","subject":"Re: git-format-patch little gripe","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-11-03T20:53:58Z","receivedAt":"2006-11-03T20:53:58Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Luben Tuikov wrote:\n\n> --- Junio C Hamano wrote:\n\n>> One thing we talked about but nobody stepped up to code [*1*] is\n>> to give \"git-format-patch --stdin\" that reads list of commits,\n>> and runs \"git-diff-tree --pretty --stat --summary -p $commit\".\n>> With that, we could do something like:\n>> \n>> git rev-list linus..orinoco | git format-patch --stdin\n> \n> That'd be swell to have.\n> \n>> Your \"git-format-patch --single $commit\" is a shorthand for a\n>> degenerated special case of that pattern.\n> \n> Yes, except that I'd have to paste the sha-1 into the terminal\n> rather than on the command line. This again proves that the current\n> git-format-patch to mean \"..HEAD\" is horribly broken.\n\nFirst, you could have behavior you wanted by using additional option\n--single, i.e. git-format-patch --single would mean\ngit-format-patch ^..\n\nBut I agree that it is somewhat counter-intuitive that for all\nother commands which use revision list means lineage\nof while for git-format-patch it means ..HEAD\n... and we have .. shortcut (two characters more) to mean\nthe same.\n \nAnother command with non-obvious UI is git-format-branch, which\nis not CLI equivalent of gitk/qgit (doesn't accept revision range\nfor example).\n\n>> You cannot do patch-id based filtering with this form, but I see\n>> that \"single\" is often wanted on the list and #git, and people\n>> who want it do not care about patch-id based filtering at all.\n> \n> The reason it is wanted is because it is _intuitive_. This is\n> what engineers (of different backgrounds) tend to intuitively think\n> and assume given git's structure and the nature and meaning of\n> what an is in git, only to be surprised later when that\n> assumption is completely broken by git-format-patch.\n\nIntuiveness is in the eye of beholder :-)\n\n>> And I do not think it is that \"they do not realize how much they\n>> would be missing without patch-id filtering\", in this case. So\n>> the above command line would probably be Ok.\n> \n> I do not think they'd be missing _anything_. After all,\n> \"git-format-patch ..HEAD\" is also intuitive.\n\nAnd we have .. shortcut. \n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"297260","messageId":"7v3b905fqi.fsf@assigned-by-dhcp.cox.net","threadId":"43109","inReplyTo":"20061103195253.9244.qmail@web31814.mail.mud.yahoo.com","subject":"Re: git-format-patch little gripe","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-03T22:26:29Z","receivedAt":"2006-11-03T22:26:29Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Luben Tuikov writes:\n\n> Also I doubt how many people actually have coded in their scripts\n> \"git-format-patch \" to mead by default \"..HEAD\" -- I'd think\n> that maintainers always want to know the \"end point\" and would always\n> use the .. format, instead of presuming where/what their HEAD is.\n\nWell, the answer would be \"do not script around Porcelain\".\n\n> Sorry it's my rant. I know it's not your fault.\n\nI do not even think there is any \"fault\" there, to be honest, so\nthere is no need to apologize. The format-patch command does\nwhat it was designed to do and does it well -- format a sequence\nof patches for upstream submission.\n\nIf you want a single patch, you can always say \"git show\", by\nthe way.\n\n"},{"id":"298704","messageId":"87velwupk6.wl%cworth@cworth.org","threadId":"43109","inReplyTo":"7v3b905fqi.fsf@assigned-by-dhcp.cox.net","subject":"Re: git-format-patch little gripe","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2006-11-03T22:35:05Z","receivedAt":"2006-11-03T22:35:05Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Fri, 03 Nov 2006 14:26:29 -0800, Junio C Hamano wrote:\n> If you want a single patch, you can always say \"git show\", by\n> the way.\n\nUgh.\n\nI mean, git show is fine for displaying something to just read it, but\nif the results are to be fed back into git at some point, then\ngit-show is pretty useless, (throws away commit message, author,\ntimestamp, etc.).\n\n-Carl\n"},{"id":"295518","messageId":"20061103231647.GB6970@coredump.intra.peff.net","threadId":"43109","inReplyTo":"87velwupk6.wl%cworth@cworth.org","subject":"Re: git-format-patch little gripe","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2006-11-03T23:16:47Z","receivedAt":"2006-11-03T23:16:47Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Nov 03, 2006 at 02:35:05PM -0800, Carl Worth wrote:\n\n> I mean, git show is fine for displaying something to just read it, but\n> if the results are to be fed back into git at some point, then\n> git-show is pretty useless, (throws away commit message, author,\n> timestamp, etc.).\n\nTry\n git-show --pretty=email\nor even\n git-show --pretty=email --stat -p\n\n"},{"id":"293856","messageId":"eigjql$ql$2@sea.gmane.org","threadId":"43109","inReplyTo":"20061103231647.GB6970@coredump.intra.peff.net","subject":"Re: git-format-patch little gripe","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-11-03T23:37:23Z","receivedAt":"2006-11-03T23:37:23Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Jeff King wrote:\n\n> On Fri, Nov 03, 2006 at 02:35:05PM -0800, Carl Worth wrote:\n> \n>> I mean, git show is fine for displaying something to just read it, but\n>> if the results are to be fed back into git at some point, then\n>> git-show is pretty useless, (throws away commit message, author,\n>> timestamp, etc.).\n> \n> Try\n> git-show --pretty=email\n> or even\n> git-show --pretty=email --stat -p\n\nYAUO, Yet Another Undocumented Option. ::sigh::\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"294083","messageId":"Pine.LNX.4.64.0611031640140.25218@g5.osdl.org","threadId":"43109","inReplyTo":"eigjql$ql$2@sea.gmane.org","subject":"Re: git-format-patch little gripe","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-11-04T00:44:45Z","receivedAt":"2006-11-04T00:44:45Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sat, 4 Nov 2006, Jakub Narebski wrote:\n>\n> YAUO, Yet Another Undocumented Option. ::sigh::\n\nThe \"--pretty=xxx\" is certainly not new, and it's not even totally \nundocumented. It's mentioned in several of the examples in various forms.\n\nAll the logging commands take the \"pretty\" argument.\n\nTry\n\n\tgit log --pretty={oneline,short,medium,full,fuller,raw}\n\n(and the same things work for \"git whatchanged\" and \"git show\" etc)\n\n"},{"id":"298318","messageId":"200611040205.22305.jnareb@gmail.com","threadId":"43109","inReplyTo":"Pine.LNX.4.64.0611031640140.25218@g5.osdl.org","subject":"Re: git-format-patch little gripe","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-11-04T01:05:21Z","receivedAt":"2006-11-04T01:05:21Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Linus Torvalds wrote:\n> \n> On Sat, 4 Nov 2006, Jakub Narebski wrote:\n>>\n>> YAUO, Yet Another Undocumented Option. ::sigh::\n> \n> The \"--pretty=xxx\" is certainly not new, and it's not even totally \n> undocumented. It's mentioned in several of the examples in various forms.\n> \n> All the logging commands take the \"pretty\" argument.\n> \n> Try\n> \n> \tgit log --pretty={oneline,short,medium,full,fuller,raw}\n> \n> (and the same things work for \"git whatchanged\" and \"git show\" etc)\n\nI meant git show --pretty=email option. Sorry for confusion.\n\n-- \nJakub Narebski\n"}]}