Re: [Savannah-hackers-public] Pusing to Git repo declined

[Paul Smith]

On Thu, 2016-05-26 at 13:41 -0700, Jim Meyering wrote:
> On Tue, May 24, 2016 at 10:30 PM, Aljosha Papsch wrote:
> > Thanks for the clarification. I will fix these files now. While forcing
> > users to push clean files is unexpected for user, I guess it would be great
> > if these messages were warnings and would not result in a fatal error.
> > Users could then decide for themselves whether to clean up files, in the
> > sense "You have been warned". Is that possible?

The problem with this is that it's not possible in Git to "change" a
commit once it's been made, except by "rewriting history", and once a
commit is pushed to a public server it's typically a very bad idea to
rewrite its history.

So, if you simply warn about these problems but let the commit push
succeed, then there is no way for the user to clean up the mess except
by adding a new commit on top which undoes the problems.  It is really
unpleasant, in the project history, to see a constant set of "push a
change, push a cleanup to the change" commits.

If the project is serious about enforcing these habits then the right
way to do it is by rejecting commits that don't meet the criteria, so
that the user can fix them and avoid incorrect commits appearing in the
repository in the first place.

Re: [Savannah-hackers-public] Pusing to Git repo declined

[Jim Meyering]

On Tue, May 24, 2016 at 10:30 PM, Aljosha Papsch  wrote:
> On 25.05.2016 05:27, Bob Proulx wrote:
>>
>> Assaf Gordon wrote:
>>>
>>> Hello Aljosha,

 Aljosha Papsch wrote:
 today I tried pushing to a Git repository via SSH, but it fails:
 ...
 remote: error: hook declined to update refs/heads/master
 ...
 Why does Savannah reject my changes? If it's really about coding style,
 as the messages suggest, I will be happy fixing those. But I can't
 believe
 Savannah is trying to make me push clean files :) Is there some other
 issue?
>>>
>>> Let me check that and hopefully I'll have an answer soon.
>>
>> Honestly I when I set up that repository I simply cloned the coreutils
>> setup.  It has that configuration.  Sometimes the cut-n-paste paradigm
>> can catch up with you.  That is the case here and how I did it.
>>
>> However I personally would consider it.  Most of the issues it was
>> complaining about look like real issues to me.  It was complaining
>> about spaces before TABs.  That is almost always a bad thing.  It
>> complains if the file doesn't end with a newline.  Not ending with a
>> newline causes the file to be treated as a binary file instead of a
>> text file since by definition text files are lines terminated by
>> newlines.  Things like that are actually very important errors.  The
>> trailing whitespace is a much lessor issue but tends to be a problem
>> for gratuitious diffs between different committers.
>>
>> I have removed that hook from the git repository.  You won't get that
>> rejection from it for any content now.  Sorry for the unpleasant
>> interaction from my cloning another setup for you.
>>
>> Bob
>>
> Thanks for the clarification. I will fix these files now. While forcing
> users to push clean files is unexpected for user, I guess it would be great
> if
> these messages were warnings and would not result in a fatal error.
> Users could then decide for themselves whether to clean up files, in the
> sense "You have been warned". Is that possible?

This is a last-resort policy-enforcer set by the package
maintainer(s). One typically has first-level notifiers (editor, tools)
to warn about fundamental policy/cleanliness violations like this, so
that it's only in the unusual event that a violation gets past those
that it will trigger a push rejection.

Of course, if those who contribute to a particular package want a
different policy, someone here can change your instance of the commit
hook to work differently.