On Sat, Mar 21, 2009 at 10:56:26AM -0700, James Pickens wrote: > 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? 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 -- 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
