{"thread":{"id":"30017","subject":"Has anyone written a hook to block fast forward merges to a branch?","startedAt":"2012-03-21T18:22:46Z","lastAt":"2012-03-21T21:22:01Z","messageCount":6,"participants":["Chris Patti","Jeff King","Neal Kreitzinger"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"187413","messageId":"CAJ8P3RCQjh1ehjsihAmu8roC1aeRo=R0sN2Wm0Y4bVk=st4ivw@mail.gmail.com","threadId":"30017","inReplyTo":null,"subject":"Has anyone written a hook to block fast forward merges to a branch?","fromName":"Chris Patti","fromEmail":"cpatti@gmail.com","sentAt":"2012-03-21T18:22:46Z","receivedAt":"2012-03-21T18:22:46Z","isPatch":false,"sender":{"key":"cpatti@gmail.com","avatar":null},"body":"I know there are hooks out there to block various other kinds of\nchange, but I was wondering if anyone had specifically ever written\none to block fast forward merges.\n\nThanks,\n-Chris\n\n\n-- \nChristopher Patti - Geek At Large | GTalk: cpatti@gmail.com | AIM:\nchrisfeohpatti | P: (260) 54PATTI\n\"Technology challenges art, art inspires technology.\" - John Lasseter, Pixar\n"},{"id":"187415","messageId":"20120321184051.GB14638@sigill.intra.peff.net","threadId":"30017","inReplyTo":"CAJ8P3RCQjh1ehjsihAmu8roC1aeRo=R0sN2Wm0Y4bVk=st4ivw@mail.gmail.com","subject":"Re: Has anyone written a hook to block fast forward merges to a branch?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-03-21T18:40:51Z","receivedAt":"2012-03-21T18:40:51Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Mar 21, 2012 at 02:22:46PM -0400, Chris Patti wrote:\n\n> I know there are hooks out there to block various other kinds of\n> change, but I was wondering if anyone had specifically ever written\n> one to block fast forward merges.\n\nHow would you detect them? If I do a fast-forward merge, the result is\nindistinguishable from simply building the commits directly on the\nbranch in the first place.\n\nIf you mean \"nobody should ever build commits directly on master, but\nalways be merging in commits from topic branches\", then that is easier\nto enforce; just look for non-merge commits down the --first-parent\nline, and reject if you find any. I think you could do it with:\n\n  git rev-list --max-parents=1 --first-parent $OLD..$NEW\n\nIf that produces output, then somebody build directly on master (or did\na backwards master->topic merge, but if you care about first-parents\nlineage, then that is equally bad).\n\n-Peff\n"},{"id":"187430","messageId":"4F6A3ACA.6050100@gmail.com","threadId":"30017","inReplyTo":"CAJ8P3RCQjh1ehjsihAmu8roC1aeRo=R0sN2Wm0Y4bVk=st4ivw@mail.gmail.com","subject":"Re: Has anyone written a hook to block fast forward merges to a branch?","fromName":"Neal Kreitzinger","fromEmail":"nkreitzinger@gmail.com","sentAt":"2012-03-21T20:32:10Z","receivedAt":"2012-03-21T20:32:10Z","isPatch":false,"sender":{"key":"nkreitzinger@gmail.com","avatar":null},"body":"On 3/21/2012 1:22 PM, Chris Patti wrote:\n> I know there are hooks out there to block various other kinds of\n> change, but I was wondering if anyone had specifically ever written\n> one to block fast forward merges.\n>\nMaybe git-merge --no-ff would also be helpful to \"do what you want\".\n\n(I'm not sure why you would tell people they can't do their work really \nfast or rebase to make it look like they did, but it seems that's what \nyou are also implying.)\n\nv/r,\nneal\n"},{"id":"187432","messageId":"20120321204333.GB15021@sigill.intra.peff.net","threadId":"30017","inReplyTo":"4F6A3ACA.6050100@gmail.com","subject":"Re: Has anyone written a hook to block fast forward merges to a branch?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-03-21T20:43:33Z","receivedAt":"2012-03-21T20:43:33Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Mar 21, 2012 at 03:32:10PM -0500, Neal Kreitzinger wrote:\n\n> On 3/21/2012 1:22 PM, Chris Patti wrote:\n> >I know there are hooks out there to block various other kinds of\n> >change, but I was wondering if anyone had specifically ever written\n> >one to block fast forward merges.\n> >\n> Maybe git-merge --no-ff would also be helpful to \"do what you want\".\n\nWhen I wrote my response, I assumed the intent was that people _should_\nbe using --no-ff, but that he wanted to enforce it via hook during a\npush to a central repository.\n\nReading it again, I'm not sure whether that is the case or not. If not,\nthe disregard my original response. :)\n\n-Peff\n"},{"id":"187434","messageId":"4F6A44AD.4040600@gmail.com","threadId":"30017","inReplyTo":"20120321204333.GB15021@sigill.intra.peff.net","subject":"Re: Has anyone written a hook to block fast forward merges to a branch?","fromName":"Neal Kreitzinger","fromEmail":"nkreitzinger@gmail.com","sentAt":"2012-03-21T21:14:21Z","receivedAt":"2012-03-21T21:14:21Z","isPatch":false,"sender":{"key":"nkreitzinger@gmail.com","avatar":null},"body":"On 3/21/2012 3:43 PM, Jeff King wrote:\n> On Wed, Mar 21, 2012 at 03:32:10PM -0500, Neal Kreitzinger wrote:\n>\n>> On 3/21/2012 1:22 PM, Chris Patti wrote:\n>>> I know there are hooks out there to block various other kinds of\n>>> change, but I was wondering if anyone had specifically ever\n>>> written one to block fast forward merges.\n>>>\n>> Maybe git-merge --no-ff would also be helpful to \"do what you\n>> want\".\n>\n> When I wrote my response, I assumed the intent was that people\n> _should_ be using --no-ff, but that he wanted to enforce it via hook\n> during a push to a central repository.\n>\n> Reading it again, I'm not sure whether that is the case or not. If\n> not, the disregard my original response. :)\n>\nWould your script only work at \"push time\", or would it also work at\n\"commit time\"?  I'm not sure at what point he thinks he wants to enforce \nit.  I don't think git yet knows the info your script is asking for at \n\"commit time\" (ie, pre-commit hook and its brethren), and by the time it \ndoes know it's too late to block the commit locally.  Maybe it does know \nthat inof at the point one of those \"commit time\" hooks runs.  I haven't \ntried it.\n\nv/r,\nneal\n"},{"id":"187436","messageId":"20120321212201.GA16734@sigill.intra.peff.net","threadId":"30017","inReplyTo":"4F6A44AD.4040600@gmail.com","subject":"Re: Has anyone written a hook to block fast forward merges to a branch?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-03-21T21:22:01Z","receivedAt":"2012-03-21T21:22:01Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Mar 21, 2012 at 04:14:21PM -0500, Neal Kreitzinger wrote:\n\n> >When I wrote my response, I assumed the intent was that people\n> >_should_ be using --no-ff, but that he wanted to enforce it via hook\n> >during a push to a central repository.\n> >\n> Would your script only work at \"push time\", or would it also work at\n> \"commit time\"?  I'm not sure at what point he thinks he wants to\n> enforce it.  I don't think git yet knows the info your script is\n> asking for at \"commit time\" (ie, pre-commit hook and its brethren),\n> and by the time it does know it's too late to block the commit\n> locally.  Maybe it does know that inof at the point one of those\n> \"commit time\" hooks runs.  I haven't tried it.\n\nCompletely untested, but you could probably do something like this in a\npre-commit hook:\n\n  if test \"`git symbolic-ref HEAD 2>/dev/null`\" = \"refs/heads/master\" &&\n     ! test -e \"`git rev-parse --git-dir`/MERGE_HEAD\"\n  then\n    echo >&2 \"Don't commit right on master. Go make a topic branch.\"\n    exit 1\n  fi\n\nbut I'm not sure if that would catch fast-forward merges or not. You\nmight also have to do an ancestry check against MERGE_HEAD.\n\nWhether such a thing would be useful depends on your workflow and\nexactly what you're trying to achieve. Usually people try to enforce\npolicy like this on pushes, just because that is an easy central point\n(e.g., somebody who forgets to use topic branches or --no-ff may also\nforget to set up their hooks; but if you have a central publishing\npoint, it's easy to set up the policies there just once).\n\n-Peff\n"}]}