On Tue, 21 Jan 2020 at 17:06, Jason Merrill <ja...@redhat.com> wrote: > > On Tue, Jan 21, 2020 at 11:52 AM Richard Earnshaw (lists) < > richard.earns...@arm.com> wrote: > > > On 21/01/2020 16:43, Nathan Sidwell wrote: > > > On 1/21/20 11:38 AM, Richard Earnshaw (lists) wrote: > > >> On 21/01/2020 16:14, Jonathan Wakely wrote: > > >>> On Tue, 21 Jan 2020 at 16:03, Martin Liška <mli...@suse.cz> wrote: > > >>>> > > >>>> Can you please remove the hook for user branches likes: > > >>>> > > >>>> $ git push origin me/filter-non-common > > >>>> Enumerating objects: 27, done. > > >>>> Counting objects: 100% (27/27), done. > > >>>> Delta compression using up to 16 threads > > >>>> Compressing objects: 100% (14/14), done. > > >>>> Writing objects: 100% (14/14), 1.77 KiB | 1.77 MiB/s, done. > > >>>> Total 14 (delta 13), reused 0 (delta 0) > > >>>> remote: *** The first line of a commit message should be a short > > >>>> description of the change, not a single word. > > >>>> remote: error: hook declined to update > > >>>> refs/users/marxin/heads/filter-non-common > > >>>> To git+ssh://gcc.gnu.org/git/gcc.git > > >>>> ! [remote rejected] me/filter-non-common -> > > >>>> refs/users/marxin/heads/filter-non-common (hook declined) > > >>>> error: failed to push some refs to 'git+ssh://gcc.gnu.org/git/gcc.git > > ' > > >>> > > >>> Requiring slightly better messages than just a single word doesn't > > >>> seem to restrictive to me, even on user branches. > > > > > > plus it teaches you good practice in a safe area. > > > > > >> I agree. What's more, if you ever want to merge the branch into trunk > > >> you'll need to fix such messages, so why not just get them right in > > >> the first place? > > > > > > Are you using 'merge' with some meaning other than git merge? because > > > merging to trunk is verboeten. > > > > In the sense 'integrate' your change into trunk. In practice I mean by > > a fast-forward push, of course. > > > > My commit messages while I'm working on something rarely have anything to > do with the commit messages that I eventually push to trunk; there's no > point in writing extensive description of stuff I might discard anyway. > When I'm done developing a change I then squash and reorganize commits and > write the commit message for public consumption.
Whether they make it to trunk or not doesn't really change the fact that a one-word message is poor. If it's only on your local machine, do what you like. The hook only complains when such a commit is published on gcc.gnu.org.
