Re: [RFE] Migration to gitlab

[Eli Zaretskii]

> Date: Wed, 20 Mar 2019 00:59:41 +0300
> From: Konstantin Kharlamov <address@hidden>
> Cc: Dmitry Gutov <address@hidden>, address@hidden,
>       address@hidden
> 
> > It is all too easy to disable/bypass the hooks, as you probably know
> > very well.  So this doesn't sound like an important issue to me.
> 
> It looks too easy when you already know how it works. An aribtrary 
> newcomer don't.

I seriously doubt that.  I just now typed into a browser search window
"git bypass commit hooks" and the first hit was exactly what I wanted:

  https://stackoverflow.com/questions/7230820/skip-git-commit-hooks

You will have this as the first hit if you do this from Emacs as well:

  M-s M-w git bypass commit hooks RET

> When a newbie wants to change a code, they don't need to know all 
> contribution details, because they're in hacking stage.

They don't need to know, the commit hook will tell them.  And
bypassing commit hooks is not an Emacs thing, it's a Git thing.

> Btw, Emacs already has at least one git hook, and it's so annoying!

You can disable the hooks locally if you want.

> My point is: moving these destructive checks to the moment of the 
> actual contribution to upstream (i.e. the gitlab CI that runs for every 
> merge-request) would make more pleasant experience for contributors, 
> whilst not taking anything from maintainers (sure, "fix unit-test 
> failures that your commit caused" is something that a contributor could 
> probably figure out themselves).

And my point is that we are once again arguing about very much minor
issues, without doing anything about, nor even touching, the more
important ones.  E.g., I asked up-thread whether you knew how many
people review patches for Emacs; did you follow up on that?  This is
IMO much more important for Emacs development and eventually for its
future than whether our CI will be from Gitlab or from somewhere else,
definitely more important than the commit hooks issue.