Re: [Savannah-hackers-public] Pusing to Git repo declined
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
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.