Re: Disallow amending published commits?

[Peter Harris <git@peter.is-a-geek.org>]

On Sat, Mar 21, 2009 at 6:49 PM, James Pickens wrote:
> On Sat, Mar 21, 2009, Peter Harris <git@peter.is-a-geek.org> 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