{"thread":{"id":"18449","subject":"Disallow amending published commits?","startedAt":"2009-03-21T17:56:26Z","lastAt":"2009-03-22T15:15:08Z","messageCount":9,"participants":["James Pickens","Peter Harris","Jeff King","Nicolas Sebrecht"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"108804","messageId":"885649360903211056u38ff6cabxbe1a17d57faaa0c4@mail.gmail.com","threadId":"18449","inReplyTo":null,"subject":"Disallow amending published commits?","fromName":"James Pickens","fromEmail":"jepicken@gmail.com","sentAt":"2009-03-21T17:56:26Z","receivedAt":"2009-03-21T17:56:26Z","isPatch":false,"sender":{"key":"jepicken@gmail.com","avatar":null},"body":"I wanted to have a pre-commit hook that would prevent users from\namending a commit that had already been published, but I couldn't\nfind any way in the pre-commit hook to figure out if --amend was\nused. Is there a way to do that? Or any better way to disallow\namending published commits?\n\nThanks\nJames\n"},{"id":"108805","messageId":"eaa105840903211146s4ff398e3qa8b570a8d29a83f4@mail.gmail.com","threadId":"18449","inReplyTo":"885649360903211056u38ff6cabxbe1a17d57faaa0c4@mail.gmail.com","subject":"Re: Disallow amending published commits?","fromName":"Peter Harris","fromEmail":"git@peter.is-a-geek.org","sentAt":"2009-03-21T18:46:43Z","receivedAt":"2009-03-21T18:46:43Z","isPatch":false,"sender":{"key":"git@peter.is-a-geek.org","avatar":null},"body":"On Sat, Mar 21, 2009 at 1:56 PM, James Pickens wrote:\n> I wanted to have a pre-commit hook that would prevent users from\n> amending a commit that had already been published, but I couldn't\n> find any way in the pre-commit hook to figure out if --amend was\n> used.  Is there a way to do that?  Or any better way to disallow\n> amending published commits?\n\nAn amended commit will have a new SHA1, and therefore git will treat\nit as an entirely different commit. Trying to push an amended history\nis 'non fast forward' in git terminology, since it involves a rewind\nof existing history.\n\nSet receive.denyNonFastForwards if you don't want people to be able to\namend (or otherwise rewind) published history.\n\nPeter Harris\n"},{"id":"108846","messageId":"885649360903211549h751c19e6sbaa0e07a14413d19@mail.gmail.com","threadId":"18449","inReplyTo":"eaa105840903211146s4ff398e3qa8b570a8d29a83f4@mail.gmail.com","subject":"Re: Disallow amending published commits?","fromName":"James Pickens","fromEmail":"jepicken@gmail.com","sentAt":"2009-03-21T22:49:46Z","receivedAt":"2009-03-21T22:49:46Z","isPatch":false,"sender":{"key":"jepicken@gmail.com","avatar":null},"body":"[Resend since I forgot to cc the list]\n\nOn Sat, Mar 21, 2009, Peter Harris wrote:\n> An amended commit will have a new SHA1, and therefore git will treat\n> it as an entirely different commit. Trying to push an amended history\n> is 'non fast forward' in git terminology, since it involves a rewind\n> of existing history.\n>\n> Set receive.denyNonFastForwards if you don't want people to be able to\n> amend (or otherwise rewind) published history.\n\nThanks, but unfortunately that won't work in our workflow. Users never\npush their changes; instead, they do a turnin to a continuous integration\nserver. The server clones the central repo, pulls their changes into the\nclone, builds and tests it, then pushes to the central repo if it passes\nthe tests. So integration happens via 'pull' instead of 'push'.\n\nWe can't force the pulls to be fast forward only, because we need to allow\nturnins from multiple users to be built and tested in parallel, without\nrequiring users to pull from each other or otherwise coordinate their\nturnins.\n\nJames\n"},{"id":"108864","messageId":"eaa105840903211853p65327ffdvebbe28da5f256871@mail.gmail.com","threadId":"18449","inReplyTo":"885649360903211549h751c19e6sbaa0e07a14413d19@mail.gmail.com","subject":"Re: Disallow amending published commits?","fromName":"Peter Harris","fromEmail":"git@peter.is-a-geek.org","sentAt":"2009-03-22T01:53:49Z","receivedAt":"2009-03-22T01:53:49Z","isPatch":false,"sender":{"key":"git@peter.is-a-geek.org","avatar":null},"body":"On Sat, Mar 21, 2009 at 6:49 PM, James Pickens wrote:\n> On Sat, Mar 21, 2009, Peter Harris wrote:\n>> Set receive.denyNonFastForwards if you don't want people to be able to\n>> amend (or otherwise rewind) published history.\n>\n> Thanks, but unfortunately that won't work in our workflow.  Users never\n> push their changes; instead, they do a turnin to a continuous integration\n> server.  The server clones the central repo, pulls their changes into the\n> clone, builds and tests it, then pushes to the central repo if it passes\n> the tests.  So integration happens via 'pull' instead of 'push'.\n>\n> We can't force the pulls to be fast forward only, because we need to allow\n> turnins from multiple users to be built and tested in parallel, without\n> requiring users to pull from each other or otherwise coordinate their\n> turnins.\n\nOkay. So in that workflow, you won't ever lose the original history.\n\nIf someone creates an alternate history that differs only slightly,\nodds are your continuous integration server will get a merge conflict.\nPresumably it will reject the pull request at that point.\n\nIf it doesn't conflict, you'll have both alternate histories. So\nnothing is lost.\n\nMaybe I'm misunderstanding the question? (That is definitely possible.\nThe idea that a person would go to the effort of rewriting history -\nespecially when that person knows the original history would stay put\n- often enough to cause problems is like suggesting that a person\nmight write log messages in latin. I'm having a hard time envisioning\nthe need to write down a social rule about it, much less the need to\nwrite an AI to try to detect it.)\n\nPeter Harris\n"},{"id":"108865","messageId":"20090322024226.GA6766@coredump.intra.peff.net","threadId":"18449","inReplyTo":"885649360903211056u38ff6cabxbe1a17d57faaa0c4@mail.gmail.com","subject":"Re: Disallow amending published commits?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-03-22T02:42:26Z","receivedAt":"2009-03-22T02:42:26Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Mar 21, 2009 at 10:56:26AM -0700, James Pickens wrote:\n\n> I wanted to have a pre-commit hook that would prevent users from\n> amending a commit that had already been published, but I couldn't\n> find any way in the pre-commit hook to figure out if --amend was\n> used. Is there a way to do that? Or any better way to disallow\n> amending published commits?\n\nI don't think so; as somebody already mentioned, the usual time to\nresolve such issues is at push-time. However, I can see how it would be\nconvenient to catch such a problem early, since by the time you push, it\nmay be much later and you don't remember exactly why you amended instead\nof building on top (or as you indicated, your workflow may involve\npulling).\n\nI suspect the right way to go about this is to inform the pre-commit\nhook about the parents of the proposed commit. It already knows the\ncurrent branch (since it is in HEAD), and from there you should be able\nto implement any policy logic regarding changing the shape of history\n(including your request).\n\nRight now that information is totally contained within the git-commit\nprocess; probably the simplest thing would be to export a\nspace-separated list of SHA-1's to the hook.\n\n-Peff\n"},{"id":"108866","messageId":"eaa105840903211957g634f119bkf3e5adbc5d475793@mail.gmail.com","threadId":"18449","inReplyTo":"eaa105840903211853p65327ffdvebbe28da5f256871@mail.gmail.com","subject":"Re: Disallow amending published commits?","fromName":"Peter Harris","fromEmail":"git@peter.is-a-geek.org","sentAt":"2009-03-22T02:57:45Z","receivedAt":"2009-03-22T02:57:45Z","isPatch":false,"sender":{"key":"git@peter.is-a-geek.org","avatar":null},"body":"On Sat, Mar 21, 2009 at 9:53 PM, Peter Harris wrote:\n> On Sat, Mar 21, 2009 at 6:49 PM, James Pickens wrote:\n>> On Sat, Mar 21, 2009, Peter Harris wrote:\n>>> Set receive.denyNonFastForwards if you don't want people to be able to\n>>> amend (or otherwise rewind) published history.\n>>\n>> Thanks, but unfortunately that won't work in our workflow.  Users never\n>> push their changes; instead, they do a turnin to a continuous integration\n>> server.  The server clones the central repo, pulls their changes into the\n>> clone, builds and tests it, then pushes to the central repo if it passes\n>> the tests.  So integration happens via 'pull' instead of 'push'.\n>>\n>> We can't force the pulls to be fast forward only, because we need to allow\n>> turnins from multiple users to be built and tested in parallel, without\n>> requiring users to pull from each other or otherwise coordinate their\n>> turnins.\n>\n> Okay. So in that workflow, you won't ever lose the original history.\n\n(Replying to myself, since I thought of one other thing)\n\nYou could, if you wanted, 'pull' into a clean branch. Ensure that it\nwas a fast-forward, and only then merge the result into the\nintegration branch. Developers would have to sync-up with the central\nrepo, but at least they wouldn't have to sync with each other.\n\nPeter Harris\n"},{"id":"108868","messageId":"885649360903212109v316f441fvea3f498e91c0059e@mail.gmail.com","threadId":"18449","inReplyTo":"eaa105840903211853p65327ffdvebbe28da5f256871@mail.gmail.com","subject":"Re: Disallow amending published commits?","fromName":"James Pickens","fromEmail":"jepicken@gmail.com","sentAt":"2009-03-22T04:09:43Z","receivedAt":"2009-03-22T04:09:43Z","isPatch":false,"sender":{"key":"jepicken@gmail.com","avatar":null},"body":"On Sat, Mar 21, 2009, Peter Harris wrote:\n> Okay. So in that workflow, you won't ever lose the original history.\n>\n> If someone creates an alternate history that differs only slightly,\n> odds are your continuous integration server will get a merge conflict.\n> Presumably it will reject the pull request at that point.\n>\n> If it doesn't conflict, you'll have both alternate histories. So\n> nothing is lost.\n>\n> Maybe I'm misunderstanding the question? (That is definitely possible.\n> The idea that a person would go to the effort of rewriting history -\n> especially when that person knows the original history would stay put\n> - often enough to cause problems is like suggesting that a person\n> might write log messages in latin. I'm having a hard time envisioning\n> the need to write down a social rule about it, much less the need to\n> write an AI to try to detect it.)\n\nI think you understood the question perfectly, and your comments all make\nsense. Perhaps I'm just being paranoid and this won't be a problem at all.\n\nA bit of background might help explain my paranoia: I'm about to pilot Git\non a fairly large project, where none of the users have Git experience, and\nmany of them don't have much experience with any other version control\nsystem either. I had to fight hard to get this pilot approved, and a lot\nof people will be watching to see how it goes, so I'm trying to do anything\nI can to make sure it will be successful.\n\nJames\n"},{"id":"108897","messageId":"eaa105840903220719g6af88db1xccf9fba20c573570@mail.gmail.com","threadId":"18449","inReplyTo":"885649360903212109v316f441fvea3f498e91c0059e@mail.gmail.com","subject":"Re: Disallow amending published commits?","fromName":"Peter Harris","fromEmail":"git@peter.is-a-geek.org","sentAt":"2009-03-22T14:19:41Z","receivedAt":"2009-03-22T14:19:41Z","isPatch":false,"sender":{"key":"git@peter.is-a-geek.org","avatar":null},"body":"On Sun, Mar 22, 2009 at 12:09 AM, James Pickens wrote:\n> I think you understood the question perfectly, and your comments all make\n> sense.  Perhaps I'm just being paranoid and this won't be a problem at all.\n>\n> A bit of background might help explain my paranoia: I'm about to pilot Git\n> on a fairly large project, where none of the users have Git experience, and\n> many of them don't have much experience with any other version control\n> system either.  I had to fight hard to get this pilot approved, and a lot\n> of people will be watching to see how it goes, so I'm trying to do anything\n> I can to make sure it will be successful.\n\nAh, yes. I can understand your paranoia.\n\nMost new users will stick to your 'cheat sheet', and never even do\nenough research to learn that you can amend existing history, much\nless try it. A few will dig through the docs and try everything at\nleast once. I admit it; I fall into the latter category. :-)\n\nPeter Harris\n"},{"id":"108902","messageId":"20090322151508.GA13577@vidovic","threadId":"18449","inReplyTo":"885649360903212109v316f441fvea3f498e91c0059e@mail.gmail.com","subject":"Re: Disallow amending published commits?","fromName":"Nicolas Sebrecht","fromEmail":"nicolas.s-dev@laposte.net","sentAt":"2009-03-22T15:15:08Z","receivedAt":"2009-03-22T15:15:08Z","isPatch":false,"sender":{"key":"nicolas.s-dev@laposte.net","avatar":null},"body":"\nOn Sat, Mar 21, 2009 at 09:09:43PM -0700, James Pickens wrote:\n\n> I think you understood the question perfectly, and your comments all make\n> sense. Perhaps I'm just being paranoid and this won't be a problem at all.\n\nI guess it's most depending of your proposed general workflow. So, it\nmakes sense.\n\n> A bit of background might help explain my paranoia: I'm about to pilot Git\n> on a fairly large project, where none of the users have Git experience, and\n> many of them don't have much experience with any other version control\n> system either.\n\nAs I understand, a part of your workflow is based on automatic testing\nstages. It could be a good thing but I think you have to fit this into a\nmore general \"human based worflow\". I mean that parallel developments\nshould have one or more \"official maintainers\". Maintainers would have\nto care of the history integrity, assume the responsability of passing\nthe tests, etc.\n\nIMHO, good maintainers you can trust is much better than any \"more\nautomatic restrictive testing suites\".\n\nHere is a link talking about that kind of issues that you (and your\nmaintainers) may be interested in:\nhttp://kerneltrap.org/Linux/Git_Management\n\n-- \nNicolas Sebrecht\n"}]}