I wanted to have a pre-commit hook that would prevent users from
amending a commit that had already been published, but I couldn't
find any way in the pre-commit hook to figure out if --amend was
used.  Is there a way to do that?  Or any better way to disallow
amending published commits?

Thanks
James
--

[ message continues ]

An amended commit will have a new SHA1, and therefore git will treat
it as an entirely different commit. Trying to push an amended history
is 'non fast forward' in git terminology, since it involves a rewind
of existing history.

Set receive.denyNonFastForwards if you don't want people to be able to
amend (or otherwise rewind) published history.

Peter Harris
--

[ message continues ]

[Resend since I forgot to cc the list]


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.

James
--

[ message continues ]

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
--

[ message continues ]

(Replying to myself, since I thought of one other thing)

You could, if you wanted, 'pull' into a clean branch. Ensure that it
was a fast-forward, and only then merge the result into the
integration branch. Developers would have to sync-up with the central
repo, but at least they wouldn't have to sync with each other.

Peter Harris
--

[ message continues ]

I think you understood the question perfectly, and your comments all make
sense.  Perhaps I'm just being paranoid and this won't be a problem at all.

A bit of background might help explain my paranoia: I'm about to pilot Git
on a fairly large project, where none of the users have Git experience, and
many of them don't have much experience with any other version control
system either.  I had to fight hard to get this pilot approved, and a lot
of people will be watching to see how it goes, so I'm trying to do anything
I can to make sure it will be successful.

James
--

[ message continues ]

Ah, yes. I can understand your paranoia.

Most new users will stick to your 'cheat sheet', and never even do
enough research to learn that you can amend existing history, much
less try it. A few will dig through the docs and try everything at
least once. I admit it; I fall into the latter category. :-)

Peter Harris
--

[ message continues ]

I guess it's most depending of your proposed general workflow. So, it

As I understand, a part of your workflow is based on automatic testing
stages. It could be a good thing but I think you have to fit this into a
more general "human based worflow". I mean that parallel developments
should have one or more "official maintainers". Maintainers would have
to care of the history integrity, assume the responsability of passing
the tests, etc.

IMHO, good maintainers you can trust is much better than any "more
automatic restrictive testing suites".

Here is a link talking about that kind of issues that you (and your
maintainers) may be interested in:
http://kerneltrap.org/Linux/Git_Management

-- 
Nicolas Sebrecht

--

[ message continues ]

I don't think so; as somebody already mentioned, the usual time to
resolve such issues is at push-time. However, I can see how it would be
convenient to catch such a problem early, since by the time you push, it
may be much later and you don't remember exactly why you amended instead
of building on top (or as you indicated, your workflow may involve
pulling).

I suspect the right way to go about this is to inform the pre-commit
hook about the parents of the proposed commit. It already knows the
current branch (since it is in HEAD), and from there you should be able
to implement any policy logic regarding changing the shape of history
(including your request).

Right now that information is totally contained within the git-commit
process; probably the simplest thing would be to export a
space-separated list of SHA-1's to the hook.

-Peff
--

[ message continues ]