lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5871d2bd-1a9d-9cf0-e8bd-6d691ea94415@rasmusvillemoes.dk>
Date:   Wed, 27 Mar 2019 22:31:21 +0100
From:   Rasmus Villemoes <linux@...musvillemoes.dk>
To:     Jacek Anaszewski <jacek.anaszewski@...il.com>,
        Pavel Machek <pavel@....cz>,
        Uwe Kleine-König <u.kleine-koenig@...gutronix.de>
Cc:     LKML <linux-kernel@...r.kernel.org>, linux-leds@...r.kernel.org
Subject: Re: [PATCH v2 1/6] leds: netdev trigger: use memcpy in
 device_name_store

On 27/03/2019 22.20, Jacek Anaszewski wrote:

> Thanks for the heads-up. I must admit I'm hitting into that for the
> first time. After "git am" it was all OK, but it got screwed up after
> "git rebase -i". And having "commit.cleanup = scissors" set globally all
> the time is annoying if one extensively uses interactive rebase for
> rewording commit messages. It entails the need for manual removal of
> the whole stuff that appears then after actual commit message prepended
> with "#" comment characters.

Eh, no? At least, whenever I do commit or rebase -i, git automatically
inserts a trailer starting with the magic scissor line

# ------------------------ >8 ------------------------
# Do not modify or remove the line above.
# Everything below it will be ignored.

Maybe there's some other config option to get that, or it depends on git
version. But I certainly don't do anything at all other than write or
modify the commit message.

Never had a problem myself since I set commit.cleanup = scissors, but I
have had lots of my commit messages mangled, which is why I'm reacting.

> This is probably the reason why people use often other characters
> for command prompt (see the other fix for ledtrig-netdev).

Command prompt char is not the only problem; C snippets with #include or
other preprocessor directives also regularly gets mangled, as does shell
snippets with a bit of commentary.

Rasmus

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ