On Wed, 5 Feb 2014 13:39:47 -0800 (PST)
Philipp Kraus <philipp.kr...@flashpixx.de> 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
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
I think you might find  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.
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
For more options, visit https://groups.google.com/groups/opt_out.