{"thread":{"id":"17923","subject":"[RFC PATCH] hooks: add some defaults to support sane workflow to pre-commit","startedAt":"2009-02-20T18:13:10Z","lastAt":"2009-10-20T19:59:22Z","messageCount":10,"participants":["Heiko Voigt","Wincent Colaiuta","Thomas Rast","Jakub Narebski","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"105638","messageId":"499EF2B6.7060103@hvoigt.net","threadId":"17923","inReplyTo":null,"subject":"[RFC PATCH] hooks: add some defaults to support sane workflow to pre-commit","fromName":"Heiko Voigt","fromEmail":"git-list@hvoigt.net","sentAt":"2009-02-20T18:13:10Z","receivedAt":"2009-02-20T18:13:10Z","isPatch":true,"sender":{"key":"hvoigt@hvoigt.net","avatar":"https://avatars.githubusercontent.com/u/184958?v=4"},"body":"It sometimes happens that you move to a new machine and forget to setup your\nname and email address. To find this out after 10 commits can be quite\nfrustrating.\n\nAs far as I know all \"sane\" workflows involve topic branches, so\nnormally a developer will never commit directly on master but use topic\nbranch instead and merge them into master once finished.\n\nOne thing which could be dangerous is if you clone a project containing\nsubmodules. If you would immediately start working in a submodule you\nwould create commits with detached head. This can be a dangerous operation\nin terms of loosing commits and should be forbidden by default.\n\nSigned-off-by: Heiko Voigt \n---\n\nI also would like to vote for enabling some hooks by default. \n\n templates/hooks--pre-commit.sample | 23 +++++++++++++++++++++++\n 1 files changed, 23 insertions(+), 0 deletions(-)\n\ndiff --git a/templates/hooks--pre-commit.sample b/templates/hooks--pre-commit.sample\nindex 0e49279..6360da0 100755\n--- a/templates/hooks--pre-commit.sample\n+++ b/templates/hooks--pre-commit.sample\n@@ -16,3 +16,26 @@ else\n fi\n \n exec git diff-index --check --cached $against --\n+\n+# check if username and email are setup\n+if [ -z \"$(git config --global user.name)\" ]; then\n+ echo \"Please set your name and email address\"\n+ exit 1\n+fi\n+if [ -z \"$(git config --global user.email)\" ]; then\n+ echo \"Please set your name and email address\"\n+ exit 1\n+fi\n+\n+# work should always be done on a feature branch\n+if git branch | grep \"^* master\" > /dev/null; then\n+ echo \"No commits on master, please !\"\n+ exit 1\n+fi\n+\n+# do not allow commits on detached head\n+if git branch | grep \"^* (no branch)\" > /dev/null; then\n+ echo \"Commit on detached HEAD is dangerous !\"\n+ echo \"Please checkout a branch first ...\"\n+ exit 1\n+fi\n-- \n1.6.1.2.390.gba743\n"},{"id":"105652","messageId":"C95EAEB9-D520-497F-BA42-0CDCC1348340@wincent.com","threadId":"17923","inReplyTo":"499EF2B6.7060103@hvoigt.net","subject":"Re: [RFC PATCH] hooks: add some defaults to support sane workflow to pre-commit","fromName":"Wincent Colaiuta","fromEmail":"win@wincent.com","sentAt":"2009-02-20T20:49:22Z","receivedAt":"2009-02-20T20:49:22Z","isPatch":true,"sender":{"key":"greg@hurrell.net","avatar":"https://avatars.githubusercontent.com/u/7074?v=4"},"body":"El 20/2/2009, a las 19:13, Heiko Voigt escribió:\n\n> As far as I know all \"sane\" workflows involve topic branches, so\n> normally a developer will never commit directly on master but use \n> topic\n> branch instead and merge them into master once finished.\n\n(Shudder... by that definition there must be a lot of insane people \nout there!)\n\nI think what constitutes a \"sane\" workflow depends very much on the \nproject in question, the number of developers, the collaboration model \netc.\n\nI imagine there are plenty of developers (particularly those working \nalone on small or private projects) for whom working directly on \n\"master\" makes a lot of sense; after all, one of the great things \nabout distributed SCM is that what people do in their own private \nrepos is really up to them.\n\nAnd what about \"topics\" that are really just a single commit? A one \nline spelling fix, for example. Should that be done on a topic branch \nand merged in too?\n\nHorses for courses. In my own projects I work on master for some \nthings, and on topic branches for others, and I feel very sane.\n\nCheers,\nWincent\n"},{"id":"105700","messageId":"499FDDC2.90502@hvoigt.net","threadId":"17923","inReplyTo":"C95EAEB9-D520-497F-BA42-0CDCC1348340@wincent.com","subject":"Re: [RFC PATCH] hooks: add some defaults to support sane workflow to pre-commit","fromName":"Heiko Voigt","fromEmail":"git-list@hvoigt.net","sentAt":"2009-02-21T10:56:02Z","receivedAt":"2009-02-21T10:56:02Z","isPatch":true,"sender":{"key":"hvoigt@hvoigt.net","avatar":"https://avatars.githubusercontent.com/u/184958?v=4"},"body":"Wincent Colaiuta schrieb:\n> El 20/2/2009, a las 19:13, Heiko Voigt escribió:\n> \n>> As far as I know all \"sane\" workflows involve topic branches, so\n>> normally a developer will never commit directly on master but use topic\n>> branch instead and merge them into master once finished.\n> \n> (Shudder... by that definition there must be a lot of insane people out\n> there!)\n> \n> I think what constitutes a \"sane\" workflow depends very much on the\n> project in question, the number of developers, the collaboration model etc.\n\nYou are right I was thinking to specific. My goal with this RFC is to\nadd some default behaviour to git in terms of workflows and prevent some\ncommon pitfalls. \n\nThis leads me to a completely different solution to the same problem.\nHow about teaching git to inherit its hooks from the parental project\n(e.g. the one it was cloned from)? That way we are not limited to\none default behaviour but many that would match the one from the\nupstream project.\n\nThe simplest implementation would just copy the hooks directory when\ncloning and leave customizations to the user. This should probably be\ndisabled by default and enabled with a config option on the server side.\n\nWhat do you think about that?\n\ncheers Heiko\n"},{"id":"105702","messageId":"200902211216.43964.trast@student.ethz.ch","threadId":"17923","inReplyTo":"499FDDC2.90502@hvoigt.net","subject":"Re: [RFC PATCH] hooks: add some defaults to support sane workflow to pre-commit","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2009-02-21T11:16:35Z","receivedAt":"2009-02-21T11:16:35Z","isPatch":true,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Heiko Voigt wrote:\n> This leads me to a completely different solution to the same problem.\n> How about teaching git to inherit its hooks from the parental project\n> (e.g. the one it was cloned from)? That way we are not limited to\n> one default behaviour but many that would match the one from the\n> upstream project.\n[...]\n> What do you think about that?\n\nThree words: huge security hole.\n\nEspecially on cloning, where the checkout immediately afterwards\nwould already run the post-checkout hook, without any chance for the\nuser to inspect its contents.\n\nThe usual advice is to track the hooks in the repository, e.g., under\nhooks/, and instruct the users to copy them to .git/hooks/ if they\nwant them.\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"105716","messageId":"49A00215.9070106@hvoigt.net","threadId":"17923","inReplyTo":"200902211216.43964.trast@student.ethz.ch","subject":"Re: [RFC PATCH] hooks: add some defaults to support sane workflow to pre-commit","fromName":"Heiko Voigt","fromEmail":"git-list@hvoigt.net","sentAt":"2009-02-21T13:31:01Z","receivedAt":"2009-02-21T13:31:01Z","isPatch":true,"sender":{"key":"hvoigt@hvoigt.net","avatar":"https://avatars.githubusercontent.com/u/184958?v=4"},"body":"Thomas Rast schrieb:\n> Heiko Voigt wrote:\n>> This leads me to a completely different solution to the same problem.\n>> How about teaching git to inherit its hooks from the parental project\n>> (e.g. the one it was cloned from)? That way we are not limited to\n>> one default behaviour but many that would match the one from the\n>> upstream project.\n> [...]\n>> What do you think about that?\n> \n> Three words: huge security hole.\n> \n> Especially on cloning, where the checkout immediately afterwards\n> would already run the post-checkout hook, without any chance for the\n> user to inspect its contents.\n\nGood point here as well. \n\n> The usual advice is to track the hooks in the repository, e.g., under\n> hooks/, and instruct the users to copy them to .git/hooks/ if they\n> want them.\n\nI read about that possibility but it does not completely satisfy me,\nbecause a new user to a project can not just \n\n git clone url/to/somewhere\n\nand start working.\n\nHow about combining my first approach with the second idea? Teach git\ndifferent default sets of hooks. So something like:\n\n git init --workflow=\"topic-branches\"\n\nwould initialize and install a certain set of hooks.\n\nImplement the possibility to propagate this setting to the server, by\nusing a config variable or similar. This way only secure hooks will\nautomatically be inherited and the user has the benefit of a more\nspecific workflow support.\n\ncheers Heiko\n"},{"id":"105717","messageId":"m3k57jsx36.fsf@localhost.localdomain","threadId":"17923","inReplyTo":"49A00215.9070106@hvoigt.net","subject":"Re: [RFC PATCH] hooks: add some defaults to support sane workflow to pre-commit","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2009-02-21T14:05:25Z","receivedAt":"2009-02-21T14:05:25Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Heiko Voigt writes:\n\n> How about combining my first approach with the second idea? Teach git\n> different default sets of hooks. So something like:\n> \n> git init --workflow=\"topic-branches\"\n> \n> would initialize and install a certain set of hooks.\n> \n> Implement the possibility to propagate this setting to the server, by\n> using a config variable or similar. This way only secure hooks will\n> automatically be inherited and the user has the benefit of a more\n> specific workflow support.\n\nWell, for an _installation_ of git you _have_ possibility to provide\nhooks different than default ones, and that is via templates system.\nWith \"git init\" in already existing repository you would be able to\npick up new version of hooks.\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"105718","messageId":"49A01000.2000308@hvoigt.net","threadId":"17923","inReplyTo":"m3k57jsx36.fsf@localhost.localdomain","subject":"Re: [RFC PATCH] hooks: add some defaults to support sane workflow to pre-commit","fromName":"Heiko Voigt","fromEmail":"git-list@hvoigt.net","sentAt":"2009-02-21T14:30:24Z","receivedAt":"2009-02-21T14:30:24Z","isPatch":true,"sender":{"key":"hvoigt@hvoigt.net","avatar":"https://avatars.githubusercontent.com/u/184958?v=4"},"body":"Jakub Narebski schrieb:\n> Heiko Voigt writes:\n>> Implement the possibility to propagate this setting to the server, by\n>> using a config variable or similar. This way only secure hooks will\n>> automatically be inherited and the user has the benefit of a more\n>> specific workflow support.\n> \n> Well, for an _installation_ of git you _have_ possibility to provide\n> hooks different than default ones, and that is via templates system.\n> With \"git init\" in already existing repository you would be able to\n> pick up new version of hooks.\n\nShould this decision really be on an installation basis? Would basing\nthis decision on a project not be a better reflection of the reality? \n\nI have read some threads dealing with what a good book about git should\ncontain. In these threads the keyword workflows was brought up quite\noften. So maybe it would also be good to support this topic a little\nmore from the software side.\n\ncheers Heiko\n"},{"id":"107013","messageId":"49A2EDD3.5080307@hvoigt.net","threadId":"17923","inReplyTo":"49A00215.9070106@hvoigt.net","subject":"Re: [RFC PATCH] hooks: add some defaults to support sane workflow to pre-commit","fromName":"Heiko Voigt","fromEmail":"git-list@hvoigt.net","sentAt":"2009-02-23T18:41:23Z","receivedAt":"2009-02-23T18:41:23Z","isPatch":true,"sender":{"key":"hvoigt@hvoigt.net","avatar":"https://avatars.githubusercontent.com/u/184958?v=4"},"body":"Heiko Voigt schrieb:\n> How about combining my first approach with the second idea? Teach git\n> different default sets of hooks. So something like:\n> \n> git init --workflow=\"topic-branches\"\n> \n> would initialize and install a certain set of hooks.\n> \n> Implement the possibility to propagate this setting to the server, by\n> using a config variable or similar. This way only secure hooks will\n> automatically be inherited and the user has the benefit of a more\n> specific workflow support.\n\nSo I have been thinking about an actual implementation lately and here are\nsome more specifics of a possible implementation:\n\nAdd a new configuration file .gitconfig tracked in the working copy next to\n.gitignore and such. The order would then be: \n\n/etc/gitconfig\n~/.gitconfig\n$project/.gitconfig\n$project/.git/config \n\nDo not allow all options in such a file but use a specific namespace for\nwhitelisting them e.g.: project.workflow\n\nAdd hooks that are activated by default and use these configuration\nvariables to tune their behaviour. Example: \n\n[ \"$(git config project.workflow)\" = \"topic-branches\" ] && topic_branches=1\n\n# if we are in topic mode work should always be done on a feature branch\nif topic_branches && git branch | grep \"^* master\" > /dev/null; then\n echo \"No commits on master, please !\"\n exit 1\nfi\n\nSuch distributable options could also transport other values like the\ndescription for gitweb.\n\nWhat do you think?\n\ncheers Heiko\n"},{"id":"125361","messageId":"7v4opv4vjh.fsf@alter.siamese.dyndns.org","threadId":"17923","inReplyTo":"499EF2B6.7060103@hvoigt.net","subject":"Re: [RFC PATCH] hooks: add some defaults to support sane workflow to pre-commit","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-10-19T08:50:26Z","receivedAt":"2009-10-19T08:50:26Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Heiko Voigt writes:\n\n> It sometimes happens that you move to a new machine and forget to setup your\n> name and email address. To find this out after 10 commits can be quite\n> frustrating.\n\nDoesn't env_hint[] kick in in fmt_ident() in such a case, though?\n"},{"id":"125513","messageId":"20091020195922.GA1725@book.hvoigt.net","threadId":"17923","inReplyTo":"7v4opv4vjh.fsf@alter.siamese.dyndns.org","subject":"Re: Re: [RFC PATCH] hooks: add some defaults to support sane workflow to pre-commit","fromName":"Heiko Voigt","fromEmail":"hvoigt@hvoigt.net","sentAt":"2009-10-20T19:59:22Z","receivedAt":"2009-10-20T19:59:22Z","isPatch":true,"sender":{"key":"hvoigt@hvoigt.net","avatar":"https://avatars.githubusercontent.com/u/184958?v=4"},"body":"On Mon, Oct 19, 2009 at 01:50:26AM -0700, Junio C Hamano wrote:\n> Heiko Voigt writes:\n> \n> > It sometimes happens that you move to a new machine and forget to setup your\n> > name and email address. To find this out after 10 commits can be quite\n> > frustrating.\n> \n> Doesn't env_hint[] kick in in fmt_ident() in such a case, though?\n\nIt is not want you usually want. You get @ as the\ncommitter but if you are working on a workstation this is seldomly your\nemail address. At least in my experience.\n\nI would like this as a safeguard that you have done some basic setup\nbefore you create any commits.\n\ncheers Heiko\n"}]}