From: Paolo Bonzini <pbonzini@redhat.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Gleb Natapov <gleb@kernel.org>, KVM list <kvm@vger.kernel.org>
Subject: Re: [GIT PULL] KVM changes for 3.16-rc4
Date: Wed, 02 Jul 2014 00:41:36 +0200 [thread overview]
Message-ID: <53B33920.4040800@redhat.com> (raw)
In-Reply-To: <CA+55aFyLk1AWxd9r2zfrKtpawPhw53k_rBdj8kq159i=hf6xsA@mail.gmail.com>
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@redhat.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
prev parent reply other threads:[~2014-07-01 22:41 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-01 10:44 [GIT PULL] KVM changes for 3.16-rc4 Paolo Bonzini
2014-07-01 17:47 ` Linus Torvalds
2014-07-01 22:41 ` Paolo Bonzini [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53B33920.4040800@redhat.com \
--to=pbonzini@redhat.com \
--cc=gleb@kernel.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox