"Richard Hartmann" <richih.mailinglist@xxxxxxxxx> writes: > I fooled around with git a liitle bit and noticed something > rather strange. I merged two branches, creating a conflict > on purpose. When I then did a > > git commit -a > > all changes were submitted. Of course, I now have a > file with the conflict markers inlined in my repository. Not > a good thing, imo. Is there a way to make git block all > conflicting versions? The default pre-commit hook shipped with git includes this check. All you have to do is enable it: it has to be named 'pre-commit' and it has to be exacutable. In older git version you would do: $ chmod a+x .git/hooks/pre-commit while in never versions it would be $ mv .git/hooks/pre-commit.sample .git/hooks/pre-commit > Also, I would be interested in the design decissions > behind the current behaviour. Any pointers? It is a git policy that it ships with all hooks disabled. P.S. You can always bypass pre-commit hook (for example if comitting AsciiDoc files, which may include something that looks like conflict markers, or if you are committing test which includes conflicted file as one of test vectors), by using `--no-verify' option to git-commit. -- Jakub Narebski Poland ShadeHawk on #git -- 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
