On Wed, 5 Feb 2014 13:39:47 -0800 (PST) Philipp Kraus <[email protected]> wrote:
> >> It is more a "social problem" and I don't want to fix encoding > >> errors manually. > >> Mostly user does not configurate their editors correct and I get > >> after a commit > >> encoding errors within the files, so I would like to convert it > >> automatically by git, > >> in a best view OS independed. > >> > > > > For "social" issues, just reject the commit? > > > > Okay, so you would like to create a pre-push hook and check the file > encoding? Actually, I like this approach more than clean filters, but on the other hand, when pondering Git workflows, it helps to think about what "demigods" do. For instance, Linux kernel folks do not have sanity checking hooks on their many many rendez-vouz repositories--but folks asking for pull requests or submitting patches are supposed to ensure this code is properly formatted *and* the leutenants who accept and integrate their code are supposed to check the changes. So one way to solve your social problem is to have your devs not commit on "blessed" branches but rather to their own feature branches; then someone would just perlustrate the code and if everything okay, merge it into one of the blessed branches, otherwise the code would be rejected and its dev asked to fix it and force-push their changes again for review. An alternative approach is to have mandatory code review using a tool like Gerrit. I think you might find [1] enlightening in some ways. Not that you should adopt this methodology exactly, but look how they go about constant pushes to development branches and active reviewing of this code with sign-offs. 1. http://scottchacon.com/2011/08/31/github-flow.html -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
