From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: small author mixup Date: Wed, 30 Apr 2008 11:36:15 +0300 Message-ID: <48182F7F.9000400@qumranet.com> References: <1209310768-12322-1-git-send-email-avi@qumranet.com> <200804301012.05179.borntraeger@de.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Linus Torvalds , kvm-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org, Carsten Otte , git@vger.kernel.org To: Christian Borntraeger Return-path: In-Reply-To: <200804301012.05179.borntraeger@de.ibm.com> Sender: git-owner@vger.kernel.org List-Id: kvm.vger.kernel.org Christian Borntraeger wrote: > Am Sonntag, 27. April 2008 schrieb Avi Kivity: > >> Carsten Otte (4): >> s390: KVM preparation: provide hook to enable pgstes in user pagetable >> KVM: s390: interrupt subsystem, cpu timer, waitpsw >> KVM: s390: API documentation >> s390: KVM guest: detect when running on kvm >> >> Christian Borntraeger (10): >> KVM: kvm.h: __user requires compiler.h >> s390: KVM preparation: host memory management changes for s390 kvm >> s390: KVM preparation: address of the 64bit extint parm in lowcore >> KVM: s390: sie intercept handling >> KVM: s390: intercepts for privileged instructions >> KVM: s390: interprocessor communication via sigp >> KVM: s390: intercepts for diagnose instructions >> KVM: s390: add kvm to kconfig on s390 >> KVM: s390: update maintainers >> s390: KVM guest: virtio device support, and kvm hypercalls >> > > Thats interesting, some of these patches should actually be credited to > Carsten - and in fact on kvm.git master they are credited to Carsten. > > I think the problem is, that these patches contained multiple From lines. On > kvm.git the first line (Carsten) was used. When you transferred these patches > to the kvm.git-2.6.26-branch, git used the next From-line as the original one > was already removed. > > While it is not a typical case, is there a better way of specifying multiple > authors to avoid future confusion? It's probably due to my heavy use of git cherry-pick, rebase, and rebase -i. I couldn't reproduce this with a test that mimics that workflow, so either it has been fixed already, or it's a little more subtle. I don't think you should change anything to avoid this. I'll keep an eye open for this, and if it happens again I'll fix it locally and send a proper bug report to the git mailing list. -- Any sufficiently difficult bug is indistinguishable from a feature.