{"thread":{"id":"37520","subject":"[PATCH/RFC 0/2] custom format for interactive rebase todo","startedAt":"2014-09-09T04:47:56Z","lastAt":"2014-09-10T17:11:55Z","messageCount":5,"participants":["William Clifford","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":2},"messages":[{"id":"249068","messageId":"864mwhi9qu.fsf@gmail.com","threadId":"37520","inReplyTo":null,"subject":"[PATCH/RFC 0/2] custom format for interactive rebase todo","fromName":"William Clifford","fromEmail":"mr.william.clifford@gmail.com","sentAt":"2014-09-09T04:47:56Z","receivedAt":"2014-09-09T04:47:56Z","isPatch":true,"sender":{"key":"mr.william.clifford@gmail.com","avatar":"https://gravatar.com/avatar/62c3a13874636c07e8b954f7b260c0a0ee0d15bcd8ac9745c3db5bf3abf23346?d=mp&s=160"},"body":"I'm sorry if this shows up twice. I messed up the first time.\n\nI was recently in a situation of rebasing a topic branch with many\ncommits by several colleagues and I thought it would be useful if I\ncould see the author of the commit in the commit table in the rebase\ntodo file. I wanted try to squash commits by the same author where\nappropriate. With the help of Matt Boeh, we figured out how to patch in\ncustom formatting of this line, and I have been trying it out for the\nlast couple of weeks and it seems to work pretty well.\n\nA couple of examples:\n\n- `git config sequence.format \"%<(12,trunc)%ae %s\"`\n- `git config sequence.format \"%s <%aN %aE>\"`\n- `git config sequence.format \"%s%n%%n%b\"`\n\nThe first one tries to conserve linespace, which is a good idea for\nthese formats. The second one could be really long but otherwise\nharmless. I'm unsure what would happen if I tried to rebase with the\nthird style unedited or uncommented. I'm wary of casually testing it. It\ndoes not seem like a good idea, and should perhaps be discouraged.\n\nPlease let me know what you think.\n\nWilliam Clifford (2):\n Add sequence.format to interactive rebase\n Add documentation of sequence.format to interactive rebase\n\n Documentation/config.txt | 9 +++++++++\n git-rebase--interactive.sh | 14 +++++++++++++-\n 2 files changed, 22 insertions(+), 1 deletion(-)\n\n-- \nWilliam Clifford\n\nMessage-ID: <867g1dia81.fsf@gmail.com>\nX-Draft-From: (\"INBOX\")\n"},{"id":"249077","messageId":"xmqqtx4gloii.fsf@gitster.dls.corp.google.com","threadId":"37520","inReplyTo":"864mwhi9qu.fsf@gmail.com","subject":"Re: [PATCH/RFC 0/2] custom format for interactive rebase todo","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-09-09T16:58:13Z","receivedAt":"2014-09-09T16:58:13Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"William Clifford writes:\n\n> A couple of examples:\n>\n> - `git config sequence.format \"%<(12,trunc)%ae %s\"`\n> - `git config sequence.format \"%s <%aN %aE>\"`\n> - `git config sequence.format \"%s%n%%n%b\"`\n> ... I'm unsure what would happen if I tried to rebase with the\n> third style unedited or uncommented.\n\nIt should be simply forbidden. The body part may have a line that\nis similar enough (i.e. starting with one of the command words and\nthen a hexadecimal string) to confuse the sequencing machinery.\n\nOther than that safety issue, I am not fundamentally opposed to the\nidea.\n\nAs to the implementation in 1/2, your unconditional use of \">%h\" is\nwrong (you would end up including the commits from the left side).\n\nUse '%m' instead of a hardcoded '>', perhaps?\n"},{"id":"249080","messageId":"xmqqha0glo3j.fsf@gitster.dls.corp.google.com","threadId":"37520","inReplyTo":"xmqqtx4gloii.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH/RFC 0/2] custom format for interactive rebase todo","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-09-09T17:07:12Z","receivedAt":"2014-09-09T17:07:12Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> William Clifford writes:\n>\n>> A couple of examples:\n>>\n>> - `git config sequence.format \"%<(12,trunc)%ae %s\"`\n>> - `git config sequence.format \"%s <%aN %aE>\"`\n>> - `git config sequence.format \"%s%n%%n%b\"`\n>> ... I'm unsure what would happen if I tried to rebase with the\n>> third style unedited or uncommented.\n>\n> It should be simply forbidden. The body part may have a line that\n> is similar enough (i.e. starting with one of the command words and\n> then a hexadecimal string) to confuse the sequencing machinery.\n>\n> Other than that safety issue, I am not fundamentally opposed to the\n> idea.\n>\n> As to the implementation in 1/2, your unconditional use of \">%h\" is\n> wrong (you would end up including the commits from the left side).\n>\n> Use '%m' instead of a hardcoded '>', perhaps?\n\nAlso, I do not think you want to make the prepending of \"%m%h \"\nconditional. If the user for whatever silly reason asks to use a\nformat \"%m%h %m%h %m%h\", let her have that _after_ the \"%m%h \" the\nmachinery needs to operate, i.e. \"%m%h %m%h %m%h %m%h\". It is far\neasier to explain to the users and you can lose three lines from the\nsecond patch.\n"},{"id":"249132","messageId":"CAFY06=jqNEo=G7HFjHn-8i8tLMdHwg3yZdwidW_j=_Tw90tnhQ@mail.gmail.com","threadId":"37520","inReplyTo":"xmqqha0glo3j.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH/RFC 0/2] custom format for interactive rebase todo","fromName":"William Clifford","fromEmail":"mr.william.clifford@gmail.com","sentAt":"2014-09-10T14:48:14Z","receivedAt":"2014-09-10T14:48:14Z","isPatch":true,"sender":{"key":"mr.william.clifford@gmail.com","avatar":"https://gravatar.com/avatar/62c3a13874636c07e8b954f7b260c0a0ee0d15bcd8ac9745c3db5bf3abf23346?d=mp&s=160"},"body":"Thanks! I've set it up just this way and it seems to work fine.\n\nIt turns out the formatted string is processed by the shell `read`\nlater on, which happens to ignore everything after the first line, so\nit seems like it should be safe. But doing something explicit about it\nseems like a good idea in this case. I will see about actually reading\nin additional lines and raising an error, but it occurs to me that if\nI can read in the additional lines, I could also insert them as\ncomments, and then it should be as safe as any of the other comments\ninserted in the rebase todo. In any case I will look into it and\nprepare another patch.\n\nOn Tue, Sep 9, 2014 at 10:07 AM, Junio C Hamano wrote:\n> Junio C Hamano writes:\n>\n>> William Clifford writes:\n>>\n>>> A couple of examples:\n>>>\n>>> - `git config sequence.format \"%<(12,trunc)%ae %s\"`\n>>> - `git config sequence.format \"%s <%aN %aE>\"`\n>>> - `git config sequence.format \"%s%n%%n%b\"`\n>>> ... I'm unsure what would happen if I tried to rebase with the\n>>> third style unedited or uncommented.\n>>\n>> It should be simply forbidden. The body part may have a line that\n>> is similar enough (i.e. starting with one of the command words and\n>> then a hexadecimal string) to confuse the sequencing machinery.\n>>\n>> Other than that safety issue, I am not fundamentally opposed to the\n>> idea.\n>>\n>> As to the implementation in 1/2, your unconditional use of \">%h\" is\n>> wrong (you would end up including the commits from the left side).\n>>\n>> Use '%m' instead of a hardcoded '>', perhaps?\n>\n> Also, I do not think you want to make the prepending of \"%m%h \"\n> conditional. If the user for whatever silly reason asks to use a\n> format \"%m%h %m%h %m%h\", let her have that _after_ the \"%m%h \" the\n> machinery needs to operate, i.e. \"%m%h %m%h %m%h %m%h\". It is far\n> easier to explain to the users and you can lose three lines from the\n> second patch.\n\n\n\n-- \nWilliam Clifford\n"},{"id":"249138","messageId":"xmqqy4trh02s.fsf@gitster.dls.corp.google.com","threadId":"37520","inReplyTo":"CAFY06=jqNEo=G7HFjHn-8i8tLMdHwg3yZdwidW_j=_Tw90tnhQ@mail.gmail.com","subject":"Re: [PATCH/RFC 0/2] custom format for interactive rebase todo","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-09-10T17:11:55Z","receivedAt":"2014-09-10T17:11:55Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"William Clifford writes:\n\n> I will see about actually reading\n> in additional lines and raising an error, but it occurs to me that if\n> I can read in the additional lines, I could also insert them as\n> comments, and then it should be as safe as any of the other comments\n> inserted in the rebase todo.\n\n;-)\n"}]}