linux-kernel - Re: [GIT PULL] KVM changes for 3.16-rc4

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] [day] [month] [year] [list]

Message-ID: <53B33920.4040800@redhat.com>
Date:	Wed, 02 Jul 2014 00:41:36 +0200
From:	Paolo Bonzini <pbonzini@...hat.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
CC:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Gleb Natapov <gleb@...nel.org>, KVM list <kvm@...r.kernel.org>
Subject: Re: [GIT PULL] KVM changes for 3.16-rc4

Il 01/07/2014 19:47, Linus Torvalds ha scritto:
> Merges need explanations too. Tell what the branch you are merging
> does, and why you are doing the merge. Yeah, in this case the "branch"
> contains a single commit, but that *still* doesn't excuse not telling
> what the merge is, and why it exists at all.
>
> Seriously. Do "git log --merges" on current git, and look at the
> discrepancy between merge commit messages. That commit 9a630d15f16d is
> pure garbage.
>
> It's not the only crappy one, but it really does stand out. There are
> other one-liners in there, but even then they tend to have at least
> *some* semblance of actual information in them, ie
>
>     Merge branch 'for-v3.16/ti-clk-drv' of
> github.com:t-kristo/linux-pm into clk-next
>
> at least shows that there's a topic branch with a reasonable name, and
> where it comes from. I'd really prefer it to talk about what it merges
> and why, but it's still *much* better than your completely
> information-free merge message.

You're definitely right about the poor commit message.

I made this a merge because I really wanted this commit in the 3.17 
development branch too.  So I applied the patch on top of -rc1 and 
merged it into both branches (kvm-master for 3.16 and kvm-next for 
3.17).  For some reason, I did see a need to justify the merge commit in 
kvm-next:

     commit dc720f95939280f9e69cafe7389be6d0fa6f22dd
     Merge: 27e6fb5dae28 33b458d276bb
     Author: Paolo Bonzini <pbonzini@...hat.com>
     Date:   Mon Jun 30 16:51:07 2014 +0200

         Merge commit '33b458d276bb' into kvm-next

         Fix bad x86 regression introduced during merge window.

Probably still not verbose enough, but a little better.

Am I just over-engineering it and I should have simply cherry-picked it? 
  In this particular case the change is not likely to get other changes 
(and thus conflicts) in kvm-next, but in general it could.

Thanks,

Paolo
--
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/