On Sat, Mar 21, 2009 at 6:49 PM, James Pickens wrote: > On Sat, Mar 21, 2009, Peter Harris <git@xxxxxxxxxxxxxxxxxxx> wrote: >> Set receive.denyNonFastForwards if you don't want people to be able to >> amend (or otherwise rewind) published history. > > Thanks, but unfortunately that won't work in our workflow. Users never > push their changes; instead, they do a turnin to a continuous integration > server. The server clones the central repo, pulls their changes into the > clone, builds and tests it, then pushes to the central repo if it passes > the tests. So integration happens via 'pull' instead of 'push'. > > We can't force the pulls to be fast forward only, because we need to allow > turnins from multiple users to be built and tested in parallel, without > requiring users to pull from each other or otherwise coordinate their > turnins. Okay. So in that workflow, you won't ever lose the original history. If someone creates an alternate history that differs only slightly, odds are your continuous integration server will get a merge conflict. Presumably it will reject the pull request at that point. If it doesn't conflict, you'll have both alternate histories. So nothing is lost. Maybe I'm misunderstanding the question? (That is definitely possible. The idea that a person would go to the effort of rewriting history - especially when that person knows the original history would stay put - often enough to cause problems is like suggesting that a person might write log messages in latin. I'm having a hard time envisioning the need to write down a social rule about it, much less the need to write an AI to try to detect it.) Peter Harris -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
