linux-kernel - Re: [GIT PULL] DMA-mapping updates for v3.11

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 3 Jul 2013 14:02:01 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Marek Szyprowski <m.szyprowski@...sung.com>
Cc:	Stephen Rothwell <sfr@...b.auug.org.au>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL] DMA-mapping updates for v3.11

On Wed, Jul 3, 2013 at 12:58 AM, Marek Szyprowski
<m.szyprowski@...sung.com> wrote:
>
> Right, I dropped one commit, which I found in other 'for_next' kernel tree
> (the one from Russell King) before sending the pull request. What's wrong with
> this approach?

What did dropping the commit fix? Anything?

DO NOT REBASE UNLESS YOU HAVE SERIOUSLY PRESSING REASONS!

Why does this keep on coming up EVERY SINGLE RELEASE? Does nobody read my rants?

A duplicate commit not a "seriously pressing reason". It may be reason
for some introspection ("why did I and Russell end up applying the
same patch and stepping on each others toes?") but it is not in itself
at all a reason for rebasing.

Reasons for rebasing include:

 - "I am a complete moron, and I have terminally messed up my history
with merges from random places to the point where it is completely
unpullable"

 - "There are commits that are so horribly broken in the history that
I can't even revert them, because seeing them mentioned one more time
will make me go blind"

and the best one:

 - "I never made my patches public in the first place, and I'll clean
my ugly series up before posting them publicly for the first time".

but that last one shouldn't happen just before sending it to me, it
should happen a few weeks before sending to me so that linux-next has
time to digest the beauty of the rebased series.

The fact is, rebasing is a perfectly fine operation, but it's a fine
operation that causes lots of problems if those commits have ever been
public before. It means that linux-next cannot easily be compared to
what I pull (which is why Stephen complains), but it also results in
other developers not being able to trust your tree, and in the commits
randomly changing and the testing base thus not being reliable any
more (which is why I complain).

                   Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/