{"thread":{"id":"46353","subject":"pre-rebase hook: capture documentation in a <\n\nWithout this change, the sample hook does not pass a syntax check\n(sh -n):\n\n $ sh -n hooks--pre-rebase.sample\n hooks--pre-rebase.sample: line 101: syntax error near unexpected token `('\n hooks--pre-rebase.sample: line 101: ` merged into it again (either directly or indirectly).'\n\nSigned-off-by: Jonathan Nieder \nImproved-by: Junio C Hamano \nSigned-off-by: Stefan Beller \n---\n\nJunio wrote in \"What's-cooking\":\n\n> ... I do not know how well they are tested\n> in the field by people using 'master' in their everyday workflow.\n> Ideally, our release process wants to see more people using 'next'\n> in their everyday workflow to keep 'master' more stable than any\n> tagged release, but I do not have a good idea on how to encourage\n> it more than we currently do.\n\nOur internal release of git @ Google is debian experimental,\nwhich is basically the 'next' branch + this patch + another patch.\n\nAFAICT It is a resend of\nhttps://public-inbox.org/git/20120308122105.GA1562@burratino/\n\nAs Jonathan is a Debian Developer, it is easy for us to base\nour internal version onto debian experimental, but long term we may\nwant to base our internal version on the original next. :)\nTo do so, upstream this one last meaningful patch.\n\nThe 'another patch' from above is changing and hardcoding\nthe version number, which we do not want to upstream.\n\nThanks,\nStefan\n\n\n templates/hooks--pre-rebase.sample | 6 +++---\n 1 file changed, 3 insertions(+), 3 deletions(-)\n\ndiff --git a/templates/hooks--pre-rebase.sample b/templates/hooks--pre-rebase.sample\nindex 053f111..b7f81c1 100755\n--- a/templates/hooks--pre-rebase.sample\n+++ b/templates/hooks--pre-rebase.sample\n@@ -88,9 +88,7 @@ else\n \texit 1\n fi\n \n-exit 0\n-\n-################################################################\n+<<\\DOC_END\n \n This sample hook safeguards topic branches that have been\n published from being rewound.\n@@ -167,3 +165,5 @@ To compute (2):\n \tgit rev-list master..topic\n \n \tif this is empty, it is fully merged to \"master\".\n+\n+DOC_END\n-- \n1.8.5.3\n\n"},{"id":"324143","messageId":"20170711001527.mh7rcdvhxeouzbw7@genre.crustytoothpaste.net","threadId":"46353","inReplyTo":"20170710233525.11650-1-sbeller@google.com","subject":"Re: pre-rebase hook: capture documentation in a < Junio wrote in \"What's-cooking\":\n> \n> > ... I do not know how well they are tested\n> > in the field by people using 'master' in their everyday workflow.\n> > Ideally, our release process wants to see more people using 'next'\n> > in their everyday workflow to keep 'master' more stable than any\n> > tagged release, but I do not have a good idea on how to encourage\n> > it more than we currently do.\n> \n> Our internal release of git @ Google is debian experimental,\n> which is basically the 'next' branch + this patch + another patch.\n> \n> AFAICT It is a resend of\n> https://public-inbox.org/git/20120308122105.GA1562@burratino/\n> \n> As Jonathan is a Debian Developer, it is easy for us to base\n> our internal version onto debian experimental, but long term we may\n> want to base our internal version on the original next. :)\n> To do so, upstream this one last meaningful patch.\n> \n> The 'another patch' from above is changing and hardcoding\n> the version number, which we do not want to upstream.\n\nThanks for sending this in. I had wanted to do so myself so I could\neasily automate building Git packages based on the Debian packaging, but\nI never got around to it.\n-- \nbrian m. carlson / brian with sandals: Houston, Texas, US\nhttps://www.crustytoothpaste.net/~bmc | My opinion only\nOpenPGP: https://keybase.io/bk2204\n"}]}