{"thread":{"id":"43843","subject":"[PATCH v1 1/3] doc: commit: --fixup/--squash can take a commit revision","startedAt":"2016-08-14T21:46:45Z","lastAt":"2016-08-16T22:11:12Z","messageCount":16,"participants":["Philip Oakley","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":3},"messages":[{"id":"299289","messageId":"20160814214630.1312-2-philipoakley@iee.org","threadId":"43843","inReplyTo":"20160814214630.1312-1-philipoakley@iee.org","subject":"[PATCH v1 1/3] doc: commit: --fixup/--squash can take a commit revision","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2016-08-14T21:46:28Z","receivedAt":"2016-08-14T21:46:45Z","isPatch":true,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"Be clearer that the --fixup/--squash options can take any of the\ngitrevisions methods of specifying a commit, not just a 'hash'.\n\nSigned-off-by: Philip Oakley <philipoakley@iee.org>\n---\nv1\nIt's not immediately obvious what different forms the <commit>\noption can take. Spell out, and refer to the git revisions guide,\nthat any of the revision methods will work.\n\nOn a side note, if one looks at the glossary, a <commit> links to\n<commit object> which links to <object> (and only tangentially\n\"about\" revisions) which then says \"uniquely identified by the SHA-1\",\nso it is easy to think one should use the sha1 here.\n\nI only discovered this misunderstanding while following up\nother parts of this series!\n---\n Documentation/git-commit.txt | 8 ++++----\n 1 file changed, 4 insertions(+), 4 deletions(-)\n\ndiff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt\nindex e704953..3600929 100644\n--- a/Documentation/git-commit.txt\n+++ b/Documentation/git-commit.txt\n@@ -81,15 +81,15 @@ OPTIONS\n --fixup=<commit>::\n \tConstruct a commit message for use with `rebase --autosquash`.\n \tThe commit message will be the subject line from the specified\n-\tcommit with a prefix of \"fixup! \".  See linkgit:git-rebase[1]\n-\tfor details.\n+\tcommit revision with a prefix of \"fixup! \".  See linkgit:git-rebase[1]\n+\tand linkgit:gitrevisions[7] for details.\n \n --squash=<commit>::\n \tConstruct a commit message for use with `rebase --autosquash`.\n \tThe commit message subject line is taken from the specified\n-\tcommit with a prefix of \"squash! \".  Can be used with additional\n+\tcommit revision with a prefix of \"squash! \".  Can be used with additional\n \tcommit message options (`-m`/`-c`/`-C`/`-F`). See\n-\tlinkgit:git-rebase[1] for details.\n+\tlinkgit:git-rebase[1] and linkgit:gitrevisions[7] for details.\n \n --reset-author::\n \tWhen used with -C/-c/--amend options, or when committing after a\n-- \n2.9.0.windows.1\n\n"},{"id":"299290","messageId":"20160814214630.1312-1-philipoakley@iee.org","threadId":"43843","inReplyTo":null,"subject":"[PATCH v1 0/3] fixup fixup documenation","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2016-08-14T21:46:27Z","receivedAt":"2016-08-14T21:46:49Z","isPatch":true,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"With the review of the list's workflow, and failings in my personal\nworkflow, I asked a couple of questions about fixup and discovered\nthat my reading of the man pages hadn't provided the illumination\nthey hope to give. \n\nHere's three little documenation patches, and some queries to go\nwith them.\n\nPhilip Oakley (3):\n  doc: commit: --fixup/--squash can take a commit revision\n  doc: rebase: fixup! can take an object name\n  doc: rebase: clarify fixup! fixup! constraint\n\n Documentation/git-commit.txt | 8 ++++----\n Documentation/git-rebase.txt | 9 +++++----\n 2 files changed, 9 insertions(+), 8 deletions(-)\n\n-- \n2.9.0.windows.1\n\n"},{"id":"299291","messageId":"20160814214630.1312-4-philipoakley@iee.org","threadId":"43843","inReplyTo":"20160814214630.1312-1-philipoakley@iee.org","subject":"[PATCH v1 3/3] doc: rebase: clarify fixup! fixup! constraint","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2016-08-14T21:46:30Z","receivedAt":"2016-08-14T21:46:50Z","isPatch":true,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"22c5b13 (rebase -i: handle fixup! fixup! in --autosquash, 2013-06-27)\n\nSigned-off-by: Philip Oakley <philipoakley@iee.org>\n---\nv1\nthe historical discussion about this is here\nhttps://public-inbox.org/git/20130611180530.GA18488%40oinkpad.pimlott.net/\n\nI certainly misunderstood what this meant. It sounded like only one fixup! was\nallowed per commit (i.e. one mistake) - fixing two mistakes wouldn't be\nallowed. Hindsight is a wonderful thing.\n\nAlso, does 'earliest commit requiring fixup/squash' fully convey that\nits the one to fix.\n---\n Documentation/git-rebase.txt | 6 +++---\n 1 file changed, 3 insertions(+), 3 deletions(-)\n\ndiff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt\nindex 66b789a..91eb107 100644\n--- a/Documentation/git-rebase.txt\n+++ b/Documentation/git-rebase.txt\n@@ -425,9 +425,9 @@ without an explicit `--interactive`.\n \tautomatically modify the todo list of rebase -i\n \tso that the commit marked for squashing comes right after the\n \tcommit to be modified, and change the action of the moved\n-\tcommit from `pick` to `squash` (or `fixup`).  Ignores subsequent\n-\t\"fixup! \" or \"squash! \" after the first, in case you referred to an\n-\tearlier fixup/squash with `git commit --fixup/--squash`.\n+\tcommit from `pick` to `squash` (or `fixup`).  Commits with repeated\n+\t\"fixup! \" or \"squash! \" in the subject line are considered to refer\n+\tto the earliest commit requiring fixup/squash.\n +\n This option is only valid when the '--interactive' option is used.\n +\n-- \n2.9.0.windows.1\n\n"},{"id":"299292","messageId":"20160814214630.1312-3-philipoakley@iee.org","threadId":"43843","inReplyTo":"20160814214630.1312-1-philipoakley@iee.org","subject":"[PATCH v1 2/3] doc: rebase: fixup! can take an object name","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2016-08-14T21:46:29Z","receivedAt":"2016-08-14T21:46:53Z","isPatch":true,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"Since 68d5d03 (rebase: teach --autosquash to match on sha1 in addition\nto message, 2010-11-04) the commit subject can refer directly to the\ndestination object hash as a single word.)...\n\nSigned-off-by: Philip Oakley <philipoakley@iee.org>\n---\nv1\nThis is about the actual commit subject line, rather than the --fixup\noptions to the commit command.\n\nThis came out of https://public-inbox.org/git/FAE9116880074D6FA421942CCAEC368F@PhilipOakley/\nwhere I was expecting to be able to say 'fixup! <sha1> my message', but\nI can't (which would be another day's patch - fixup! <rev>! my message').\n\nOne question is whether 'standalone' is clear enough, or needs to say\n'single word revision'? (which would mean it's not 'object name')\n\nFurther, with more digging, I think that any\nrev specifier that has no spaces should work [1], despite the 68d5d's\ntitle. Though maybe during the relevant phase of rebase -i some of the\nrev specifiers may not work because of the series being rewound - dunno.\n\n[1] https://github.com/git/git/blame/v2.9.2/git-rebase--interactive.sh#L790\n---\n Documentation/git-rebase.txt | 3 ++-\n 1 file changed, 2 insertions(+), 1 deletion(-)\n\ndiff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt\nindex 0387b40..66b789a 100644\n--- a/Documentation/git-rebase.txt\n+++ b/Documentation/git-rebase.txt\n@@ -421,7 +421,8 @@ without an explicit `--interactive`.\n --no-autosquash::\n \tWhen the commit log message begins with \"squash! ...\" (or\n \t\"fixup! ...\"), and there is a commit whose title begins with\n-\tthe same ..., automatically modify the todo list of rebase -i\n+\tthe same \"...\" message, or a commit object name (standalone),\n+\tautomatically modify the todo list of rebase -i\n \tso that the commit marked for squashing comes right after the\n \tcommit to be modified, and change the action of the moved\n \tcommit from `pick` to `squash` (or `fixup`).  Ignores subsequent\n-- \n2.9.0.windows.1\n\n"},{"id":"299294","messageId":"xmqq60r3knoz.fsf@gitster.mtv.corp.google.com","threadId":"43843","inReplyTo":"20160814214630.1312-2-philipoakley@iee.org","subject":"Re: [PATCH v1 1/3] doc: commit: --fixup/--squash can take a commit revision","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-08-14T22:09:16Z","receivedAt":"2016-08-14T22:09:25Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Philip Oakley <philipoakley@iee.org> writes:\n> Be clearer that the --fixup/--squash options can take any of the\n> gitrevisions methods of specifying a commit, not just a 'hash'.\n>\n> Signed-off-by: Philip Oakley <philipoakley@iee.org>\n> ---\n> ...\n> @@ -81,15 +81,15 @@ OPTIONS\n>  --fixup=<commit>::\n>  \tConstruct a commit message for use with `rebase --autosquash`.\n>  \tThe commit message will be the subject line from the specified\n> -\tcommit with a prefix of \"fixup! \".  See linkgit:git-rebase[1]\n> -\tfor details.\n> +\tcommit revision with a prefix of \"fixup! \".  See linkgit:git-rebase[1]\n> +\tand linkgit:gitrevisions[7] for details.\n\nThe same comment applies to the other hunk, but rephrasing \"commit\"\nwith \"commit revision\" (the latter is not even in the glossary) does\nnot make it clearer at all.  Especially when discussing rebases and\nanything that rewrites commits, it can easily be mistaken as if you\nare talking about v2 of the commit by fixing up the original, but\nthat is not the impression you want to give.\n\n\"The specified commit\" is clear enough.  It may be debatable if we\nwant to talk about \"how\" to specify the commit, though.  I think the\nuse of \"commit\" in an angle-bracket-pair in the label for the\nsection, i.e. \"--fixup=<commit>\", has been considered to be clear\nenough to tell that you can use usual extended SHA-1 syntax to\nspecify the commit you want to talk about, but if so, that is not\nlimited to this entry, and I do not think this description or the\nother one for the \"--squash\" option are particularly worse than\nthose for the \"-c\" and \"-C\" options.  The description for \"-c\" does\nsay \"Take an existing commit object\", but that's like \"the specified\ncommit\" used here.\n\n"},{"id":"299295","messageId":"xmqqziofj90b.fsf@gitster.mtv.corp.google.com","threadId":"43843","inReplyTo":"20160814214630.1312-3-philipoakley@iee.org","subject":"Re: [PATCH v1 2/3] doc: rebase: fixup! can take an object name","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-08-14T22:11:48Z","receivedAt":"2016-08-14T22:11:55Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Philip Oakley <philipoakley@iee.org> writes:\n\n> Since 68d5d03 (rebase: teach --autosquash to match on sha1 in addition\n> to message, 2010-11-04) the commit subject can refer directly to the\n> destination object hash as a single word.)...\n\nThat's not an object hash but an object name (see glossary); you got\nit right in the actual patch text, though ;-).\n\n> diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt\n> index 0387b40..66b789a 100644\n> --- a/Documentation/git-rebase.txt\n> +++ b/Documentation/git-rebase.txt\n> @@ -421,7 +421,8 @@ without an explicit `--interactive`.\n>  --no-autosquash::\n>  \tWhen the commit log message begins with \"squash! ...\" (or\n>  \t\"fixup! ...\"), and there is a commit whose title begins with\n> -\tthe same ..., automatically modify the todo list of rebase -i\n> +\tthe same \"...\" message, or a commit object name (standalone),\n> +\tautomatically modify the todo list of rebase -i\n\nWhat's \"(standalone)\"?  I can understand the updated text and agree\nthat it is better than the original without that part, though.\n\n>  \tso that the commit marked for squashing comes right after the\n>  \tcommit to be modified, and change the action of the moved\n>  \tcommit from `pick` to `squash` (or `fixup`).  Ignores subsequent\n"},{"id":"299296","messageId":"xmqqvaz3j8ln.fsf@gitster.mtv.corp.google.com","threadId":"43843","inReplyTo":"20160814214630.1312-4-philipoakley@iee.org","subject":"Re: [PATCH v1 3/3] doc: rebase: clarify fixup! fixup! constraint","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-08-14T22:20:36Z","receivedAt":"2016-08-14T22:20:46Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Philip Oakley <philipoakley@iee.org> writes:\n\n> 22c5b13 (rebase -i: handle fixup! fixup! in --autosquash, 2013-06-27)\n\nThat's a noun that names a commit object.  What about it?\n\n> I certainly misunderstood what this meant. It sounded like only one fixup! was\n> allowed per commit (i.e. one mistake) - fixing two mistakes wouldn't be\n> allowed. Hindsight is a wonderful thing.\n\nI think this is about\n\n\tgit commit -m foo\n\t... some other commits\n        git commit -m 'fixup! foo'\n\t... even more other commits\n        git commit -m 'fixup! fixup! foo'\n\nThe last one is technically a fixup of the second one, but as long\nas the second one is to be applied _and_ the last one comes after\nthe second one, we could say that both of them are fix-ups for the\nvery first one.  And that is what the original text says.\n\nI have a feeling that if the editor session to edit the todo drops\nthe second one and leaves this:\n\n\tpick foo\n        fixup fixup! fixup! foo\n\nthe command _should_ notice that the second one that is required to\napply the last one is gone and error out, but probably the code does\nnot do so, and if that is the case, I think \"they fix the very first\ncommit that invited these fixups\" is a more reasonable description\nthan the more technically stringent \"fixup! fixup! is to fix what\nthe fixup! did\", which is not what the code implements.\n\n> Also, does 'earliest commit requiring fixup/squash' fully convey that\n> its the one to fix.\n\nI cannot tell if that a question or a statement?\n\n> ---\n>  Documentation/git-rebase.txt | 6 +++---\n>  1 file changed, 3 insertions(+), 3 deletions(-)\n>\n> diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt\n> index 66b789a..91eb107 100644\n> --- a/Documentation/git-rebase.txt\n> +++ b/Documentation/git-rebase.txt\n> @@ -425,9 +425,9 @@ without an explicit `--interactive`.\n>  \tautomatically modify the todo list of rebase -i\n>  \tso that the commit marked for squashing comes right after the\n>  \tcommit to be modified, and change the action of the moved\n> -\tcommit from `pick` to `squash` (or `fixup`).  Ignores subsequent\n> -\t\"fixup! \" or \"squash! \" after the first, in case you referred to an\n> -\tearlier fixup/squash with `git commit --fixup/--squash`.\n> +\tcommit from `pick` to `squash` (or `fixup`).  Commits with repeated\n> +\t\"fixup! \" or \"squash! \" in the subject line are considered to refer\n> +\tto the earliest commit requiring fixup/squash.\n>  +\n>  This option is only valid when the '--interactive' option is used.\n>  +\n"},{"id":"299297","messageId":"6ACCC850AC434350B15AADC19F02760B@PhilipOakley","threadId":"43843","inReplyTo":"xmqq60r3knoz.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH v1 1/3] doc: commit: --fixup/--squash can take a commit revision","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2016-08-14T22:45:37Z","receivedAt":"2016-08-14T22:45:47Z","isPatch":true,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Junio C Hamano\" <gitster@pobox.com>\n> Philip Oakley <philipoakley@iee.org> writes:\n>> Be clearer that the --fixup/--squash options can take any of the\n>> gitrevisions methods of specifying a commit, not just a 'hash'.\n>>\n>> Signed-off-by: Philip Oakley <philipoakley@iee.org>\n>> ---\n>> ...\n>> @@ -81,15 +81,15 @@ OPTIONS\n>>  --fixup=<commit>::\n>>  Construct a commit message for use with `rebase --autosquash`.\n>>  The commit message will be the subject line from the specified\n>> - commit with a prefix of \"fixup! \".  See linkgit:git-rebase[1]\n>> - for details.\n>> + commit revision with a prefix of \"fixup! \".  See linkgit:git-rebase[1]\n>> + and linkgit:gitrevisions[7] for details.\n>\n> The same comment applies to the other hunk, but rephrasing \"commit\"\n> with \"commit revision\" (the latter is not even in the glossary) does\n> not make it clearer at all.  Especially when discussing rebases and\n> anything that rewrites commits, it can easily be mistaken as if you\n> are talking about v2 of the commit by fixing up the original, but\n> that is not the impression you want to give.\n\nHmm, had to read that a few times before I saw what you meant regarding 'v2' \nas the revised commit.\n\n>\n> \"The specified commit\" is clear enough.  It may be debatable if we\n> want to talk about \"how\" to specify the commit, though.\n\nExactly. The latter.\n\n> I think the\n> use of \"commit\" in an angle-bracket-pair in the label for the\n> section, i.e. \"--fixup=<commit>\", has been considered to be clear\n> enough to tell that you can use usual extended SHA-1 syntax to\n> specify the commit you want to talk about,\n\nI certainly hadn't picked up on that ability to use the extended sha1 syntax \n(specifying revisions...) here.\n\nPart of the issue is that the whole fixup/squash capability is buried within \njust two documents as asides [1], and in the place it's spelt out (in \nrebase) it talks about the commit message being used, which is just part of \nthe confusion.\n\n>  but if so, that is not\n> limited to this entry, and I do not think this description or the\n> other one for the \"--squash\" option are particularly worse than\n> those for the \"-c\" and \"-C\" options.  The description for \"-c\" does\n> say \"Take an existing commit object\", but that's like \"the specified\n> commit\" used here.\n>\nOK\n--\nPhilip\n[1] just looked at the new Progit version and fixup/squash is not even \nmentioned. \n\n"},{"id":"299301","messageId":"xmqqbn0vj6ze.fsf@gitster.mtv.corp.google.com","threadId":"43843","inReplyTo":"6ACCC850AC434350B15AADC19F02760B@PhilipOakley","subject":"Re: [PATCH v1 1/3] doc: commit: --fixup/--squash can take a commit revision","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-08-14T22:55:33Z","receivedAt":"2016-08-14T22:55:41Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Philip Oakley\" <philipoakley@iee.org> writes:\n\n>> I think the\n>> use of \"commit\" in an angle-bracket-pair in the label for the\n>> section, i.e. \"--fixup=<commit>\", has been considered to be clear\n>> enough to tell that you can use usual extended SHA-1 syntax to\n>> specify the commit you want to talk about,\n>\n> I certainly hadn't picked up on that ability to use the extended sha1\n> syntax (specifying revisions...) here.\n\nBy \"has been considered\", I meant that the documentation text is\nstill open for improvement.  I just didn't find rewording \"commit\"\nwith \"commit revision\" is that improvement we need there.\n\nPerhaps we need to have somewhere central a section that explains\nvarious notations used in the documentation set.  I think it is safe\nto say something like \"unless otherwise qualified, <commit> (or any\nobject type in an angle-bracket-pair) is used as a placeholder to\ntake any acceptable way to spell object names (cf. gitrevisions for\ndetails)\" these days [*1*].\n\n\n[Footnote]\n\n*1* In ancient days I think some plumbing commands only took 40-hex\nobject names, but as far as I know they've all been updated.\n"},{"id":"299302","messageId":"BF74616BD9694719A6C0D6E75ACD9CE6@PhilipOakley","threadId":"43843","inReplyTo":"xmqqziofj90b.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH v1 2/3] doc: rebase: fixup! can take an object name","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2016-08-14T23:00:15Z","receivedAt":"2016-08-14T23:00:21Z","isPatch":true,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Junio C Hamano\" <gitster@pobox.com>\n> Philip Oakley <philipoakley@iee.org> writes:\n>\n>> Since 68d5d03 (rebase: teach --autosquash to match on sha1 in addition\n>> to message, 2010-11-04) the commit subject can refer directly to the\n>> destination object hash as a single word.)...\n>\n> That's not an object hash but an object name (see glossary); you got\n> it right in the actual patch text, though ;-).\n\nAs noted in 1/3, the glossary also needs a fix (for those who read it) to \nmake sure the name-value confusion is distinguished, with the potential \n'object names' (colloquial)  being via (git) 'revisions', while  the \ncannonical object name is the (oid) sha1 hash. Somehow folk need pointing at \nthe (broad) ways of spelling commit names rather than just the narrow sha. A \nbit of a finger and the moon problem.\n\n>\n>> diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt\n>> index 0387b40..66b789a 100644\n>> --- a/Documentation/git-rebase.txt\n>> +++ b/Documentation/git-rebase.txt\n>> @@ -421,7 +421,8 @@ without an explicit `--interactive`.\n>>  --no-autosquash::\n>>  When the commit log message begins with \"squash! ...\" (or\n>>  \"fixup! ...\"), and there is a commit whose title begins with\n>> - the same ..., automatically modify the todo list of rebase -i\n>> + the same \"...\" message, or a commit object name (standalone),\n>> + automatically modify the todo list of rebase -i\n>\n> What's \"(standalone)\"?  I can understand the updated text and agree\n> that it is better than the original without that part, though.\n\nthe 'standalone' is that it must be a single (standalone) word on the \nsubject line immediately after the \"fixup! \"(s).\n\ncommunicationg that one cannot have any extra textual notes after that word \nwas the issue that 'standalone' tried to address.\n\n--\nPhilip \n\n"},{"id":"299303","messageId":"xmqq1t1rj6n9.fsf@gitster.mtv.corp.google.com","threadId":"43843","inReplyTo":"BF74616BD9694719A6C0D6E75ACD9CE6@PhilipOakley","subject":"Re: [PATCH v1 2/3] doc: rebase: fixup! can take an object name","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-08-14T23:02:50Z","receivedAt":"2016-08-14T23:02:58Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Philip Oakley\" <philipoakley@iee.org> writes:\n\n> the 'standalone' is that it must be a single (standalone) word on the\n> subject line immediately after the \"fixup! \"(s).\n>\n> communicationg that one cannot have any extra textual notes after that\n> word was the issue that 'standalone' tried to address.\n\nPerhaps I am slow but did you mean the same thing as \"it must be a\nsingle word and nothing else on the remainder of the line\"?\n\n"},{"id":"299305","messageId":"73D1326EA2D94A1D8898884BF047C1B5@PhilipOakley","threadId":"43843","inReplyTo":"xmqqvaz3j8ln.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH v1 3/3] doc: rebase: clarify fixup! fixup! constraint","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2016-08-14T23:23:18Z","receivedAt":"2016-08-14T23:23:25Z","isPatch":true,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Junio C Hamano\" <gitster@pobox.com>\n> Philip Oakley <philipoakley@iee.org> writes:\n>\n>> 22c5b13 (rebase -i: handle fixup! fixup! in --autosquash, 2013-06-27)\n>\n> That's a noun that names a commit object.  What about it?\n\nIt's the commit that introduced the original change that's being clarified. \nIs a paragraph needed or simply \"Ref commit: ..\"\n\n>\n>> I certainly misunderstood what this meant. It sounded like only one \n>> fixup! was\n>> allowed per commit (i.e. one mistake) - fixing two mistakes wouldn't be\n>> allowed. Hindsight is a wonderful thing.\n>\n> I think this is about\n\nYes, but the original wording didn't make me think that.\n\n>\n> git commit -m foo\n> ... some other commits\n>        git commit -m 'fixup! foo'\n> ... even more other commits\n>        git commit -m 'fixup! fixup! foo'\n>\n> The last one is technically a fixup of the second one, but as long\n> as the second one is to be applied _and_ the last one comes after\n> the second one, we could say that both of them are fix-ups for the\n> very first one.  And that is what the original text says.\n\nNo. To me it said \"You can only have one fixup (commit) for any given \ncommit\". So that's one original, and one fixup. After that the autosquash \nwould leave the remaining fixup commits in their original positions in the \ncommit sequence. Hence the patch.\n\n>\n> I have a feeling that if the editor session to edit the todo drops\n> the second one and leaves this:\n>\n> pick foo\n>        fixup fixup! fixup! foo\n>\n> the command _should_ notice that the second one that is required to\n> apply the last one is gone and error out, but probably the code does\n> not do so, and if that is the case, I think \"they fix the very first\n> commit that invited these fixups\" is a more reasonable description\n> than the more technically stringent \"fixup! fixup! is to fix what\n> the fixup! did\", which is not what the code implements.\n>\n>> Also, does 'earliest commit requiring fixup/squash' fully convey that\n>> its the one to fix.\n>\n> I cannot tell if that a question or a statement?\n\nIt's a question. In your prior para you offer \"they fix the very first\n> commit that invited these fixups\" as an alternate.\nIt's when a users mental model is that they got their first fixup wrong and \nit's that fixup they are correcting, and later they add different fixups to \nthe orignal that it all gets hairy.\n(diffs must have the right sequence, while snapshots don't care - so if we \nkeep the diff sequence, we don't care about the user's mental model as the \nend results are the same).\n\nThe writeup needs to cope with the mental model rather than the end result.\n\nIt maybe that the whole 'fixup/squash' capability should be brought out as a \nsmall separate section to give space to these points and the user \nunderstanding.\n>\n>> ---\n>>  Documentation/git-rebase.txt | 6 +++---\n>>  1 file changed, 3 insertions(+), 3 deletions(-)\n>>\n>> diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt\n>> index 66b789a..91eb107 100644\n>> --- a/Documentation/git-rebase.txt\n>> +++ b/Documentation/git-rebase.txt\n>> @@ -425,9 +425,9 @@ without an explicit `--interactive`.\n>>  automatically modify the todo list of rebase -i\n>>  so that the commit marked for squashing comes right after the\n>>  commit to be modified, and change the action of the moved\n>> - commit from `pick` to `squash` (or `fixup`).  Ignores subsequent\n>> - \"fixup! \" or \"squash! \" after the first, in case you referred to an\n>> - earlier fixup/squash with `git commit --fixup/--squash`.\n>> + commit from `pick` to `squash` (or `fixup`).  Commits with repeated\n>> + \"fixup! \" or \"squash! \" in the subject line are considered to refer\n>> + to the earliest commit requiring fixup/squash.\n>>  +\n>>  This option is only valid when the '--interactive' option is used.\n>>  +\n> \n\n"},{"id":"299306","messageId":"F18C2CCC29E5470CA1374D9718B2A3E6@PhilipOakley","threadId":"43843","inReplyTo":"xmqqbn0vj6ze.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH v1 1/3] doc: commit: --fixup/--squash can take a commit revision","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2016-08-14T23:29:34Z","receivedAt":"2016-08-14T23:29:40Z","isPatch":true,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Junio C Hamano\" <gitster@pobox.com>\n> \"Philip Oakley\" <philipoakley@iee.org> writes:\n>\n>>> I think the\n>>> use of \"commit\" in an angle-bracket-pair in the label for the\n>>> section, i.e. \"--fixup=<commit>\", has been considered to be clear\n>>> enough to tell that you can use usual extended SHA-1 syntax to\n>>> specify the commit you want to talk about,\n>>\n>> I certainly hadn't picked up on that ability to use the extended sha1\n>> syntax (specifying revisions...) here.\n>\n> By \"has been considered\", I meant that the documentation text is\n> still open for improvement.  I just didn't find rewording \"commit\"\n> with \"commit revision\" is that improvement we need there.\n>\n> Perhaps we need to have somewhere central a section that explains\n> various notations used in the documentation set.  I think it is safe\n> to say something like \"unless otherwise qualified, <commit> (or any\n> object type in an angle-bracket-pair) is used as a placeholder to\n> take any acceptable way to spell object names (cf. gitrevisions for\n> details)\" these days [*1*].\n\nTrue. I'm cautious that we may accidentally still hide it in another \ndocument that the user doesn't see when reading \"this\" (or any other)  man \npage.\n\nYour sentence is short enough to be added to those few key pages that users \nrefer to to get them started in the right direction.\n\n> *1* In ancient days I think some plumbing commands only took 40-hex\n> object names, but as far as I know they've all been updated.\n> --\nPhilip \n\n"},{"id":"299307","messageId":"DDCA022C9C704F1DA20FC024B84FEB5E@PhilipOakley","threadId":"43843","inReplyTo":"xmqq1t1rj6n9.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH v1 2/3] doc: rebase: fixup! can take an object name","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2016-08-14T23:30:31Z","receivedAt":"2016-08-14T23:30:35Z","isPatch":true,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Junio C Hamano\" <gitster@pobox.com>\n> \"Philip Oakley\" <philipoakley@iee.org> writes:\n> \n>> the 'standalone' is that it must be a single (standalone) word on the\n>> subject line immediately after the \"fixup! \"(s).\n>>\n>> communicationg that one cannot have any extra textual notes after that\n>> word was the issue that 'standalone' tried to address.\n> \n> Perhaps I am slow but did you mean the same thing as \"it must be a\n> single word and nothing else on the remainder of the line\"?\n\nYes.\n\n--\nPhilip\n"},{"id":"299351","messageId":"xmqqshu6hwde.fsf@gitster.mtv.corp.google.com","threadId":"43843","inReplyTo":"73D1326EA2D94A1D8898884BF047C1B5@PhilipOakley","subject":"Re: [PATCH v1 3/3] doc: rebase: clarify fixup! fixup! constraint","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-08-15T15:42:21Z","receivedAt":"2016-08-15T15:42:29Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Philip Oakley\" <philipoakley@iee.org> writes:\n\n>> I think this is about\n>\n> Yes, but the original wording didn't make me think that.\n\nYeah, it is very plausible that it is not limited to you, and I\nagree that it is worthwhile to update the description around here.\n\n>>> Also, does 'earliest commit requiring fixup/squash' fully convey that\n>>> its the one to fix.\n>>\n>> I cannot tell if that a question or a statement?\n>\n> It's a question. In your prior para you offer \"they fix the very first\n> commit that invited these fixups\" as an alternate.\n\nI think both are equally understandable to me (but I am not the\nprimary target audience).\n\n> It's when a users mental model is that they got their first fixup\n> wrong and it's that fixup they are correcting, and later they add\n> different fixups to the orignal that it all gets hairy.\n> (diffs must have the right sequence, while snapshots don't care - so\n> if we keep the diff sequence, we don't care about the user's mental\n> model as the end results are the same).\n>\n> The writeup needs to cope with the mental model rather than the end result.\n\nYes, yes.\n\n"},{"id":"299520","messageId":"CAE3EC6B78644AA8BD07FED08AF44EAE@PhilipOakley","threadId":"43843","inReplyTo":"F18C2CCC29E5470CA1374D9718B2A3E6@PhilipOakley","subject":"Re: [PATCH v1 1/3] doc: commit: --fixup/--squash can take a commit revision","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2016-08-16T22:11:05Z","receivedAt":"2016-08-16T22:11:12Z","isPatch":true,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Philip Oakley\" <philipoakley@iee.org>\n> From: \"Junio C Hamano\" <gitster@pobox.com>\n>> \"Philip Oakley\" <philipoakley@iee.org> writes:\n>>\n>>>> I think the\n>>>> use of \"commit\" in an angle-bracket-pair in the label for the\n>>>> section, i.e. \"--fixup=<commit>\", has been considered to be clear\n>>>> enough to tell that you can use usual extended SHA-1 syntax to\n>>>> specify the commit you want to talk about,\n>>>\n>>> I certainly hadn't picked up on that ability to use the extended sha1\n>>> syntax (specifying revisions...) here.\n>>\n>> By \"has been considered\", I meant that the documentation text is\n>> still open for improvement.  I just didn't find rewording \"commit\"\n>> with \"commit revision\" is that improvement we need there.\n>>\n>> Perhaps we need to have somewhere central a section that explains\n>> various notations used in the documentation set.  I think it is safe\n>> to say something like \"unless otherwise qualified, <commit> (or any\n>> object type in an angle-bracket-pair) is used as a placeholder to\n>> take any acceptable way to spell object names (cf. gitrevisions for\n>> details)\" these days [*1*].\n>\n> True. I'm cautious that we may accidentally still hide it in another \n> document that the user doesn't see when reading \"this\" (or any other)  man \n> page.\n>\n> Your sentence is short enough to be added to those few key pages that \n> users refer to to get them started in the right direction.\n>\n>> *1* In ancient days I think some plumbing commands only took 40-hex\n>> object names, but as far as I know they've all been updated.\n>> --\n\nI'll take the patch series away and have a rework over the coming week or \nso.\n\nPhilip \n\n"}]}