From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-1.mimecast.com (us-smtp-delivery-1.mimecast.com [207.211.31.81]) by mx.groups.io with SMTP id smtpd.web12.57.1575399074670534659 for ; Tue, 03 Dec 2019 10:51:14 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=IUTVjeXi; spf=pass (domain: redhat.com, ip: 207.211.31.81, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1575399073; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=l6wTDCSr7WtrUY3ho8cs0h9SzRJwV5X8o95oMeitwXg=; b=IUTVjeXijz5JMivoDLk1DFBU02/1xb4rHSTnG5i3V1uKG1NJNr5YDIMnLTuNKkLEG+4ai7 wSjry7+aLRIAFugdKNYvkWt18lJukua3cSVf8GTqh4vEvRsQ6MgyiyMzvQ1fpnSjtRQwub 6rIMHPrXmbEcCdk63lq9uS2RqUxoaDs= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-283-QH4EN6n1OLCf5om_w0G3gw-1; Tue, 03 Dec 2019 13:51:12 -0500 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 4205B8017CC; Tue, 3 Dec 2019 18:51:11 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-117-183.ams2.redhat.com [10.36.117.183]) by smtp.corp.redhat.com (Postfix) with ESMTP id 1980E600C8; Tue, 3 Dec 2019 18:51:06 +0000 (UTC) Subject: Re: [edk2-devel] [PATCH 0/8] .mailmap: Add mailmap file to have a cleaner git history To: philmd@redhat.com Cc: devel@edk2.groups.io, Michael Kinney , Brian Richardson , Andrew Fish , Leif Lindholm References: <20191126150838.5858-1-philmd@redhat.com> From: "Laszlo Ersek" Message-ID: Date: Tue, 3 Dec 2019 19:51:06 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20191126150838.5858-1-philmd@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-MC-Unique: QH4EN6n1OLCf5om_w0G3gw-1 X-Mimecast-Spam-Score: 0 Content-Language: en-US Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Phil, (heavily trimmer CC list) On 11/26/19 16:08, Philippe Mathieu-Daud=C3=A9 via Groups.Io wrote: > Hi, >=20 > The .mailmap git feature helps fixing commit mistakes (in name/email). >=20 > The easiest way to use it is with the --use-mailmap flag: >=20 > $ git log --use-mailmap >=20 > See: > https://git-scm.com/docs/git-shortlog#_mapping_authors > https://git-scm.com/docs/git-check-mailmap#_mapping_authors >=20 > Also interesting: > https://github.com/sympy/sympy/wiki/Using-.mailmap#making-mailmap-entries >=20 > Regards, >=20 > Phil. >=20 > Philippe Mathieu-Daud=C3=A9 (8): > .mailmap: Convert emails generated by the Subversion original import > .mailmap: Fix emails from the Subversion era > .mailmap: Fix Intel emails rewritten by Microsoft Exchange Server > .mailmap: Fix emails rewritten by lists DMARC / DKIM / SPF > .mailmap: Fix incorrect email formats > .mailmap: Unify Intel email addresses format > .mailmap: Fix UTF-8 mojibaked names > .mailmap: Miscellaneous fixes on various emails >=20 > .mailmap | 221 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 221 insertions(+) > create mode 100644 .mailmap >=20 our suggestion from the stewards' confcall is to avoid cross-domain mappings, unless a contributor explicitly confirms (in an email sent from the mapped-to, i.e. "new" address) that they are OK with the mapped-from (i.e. "old") address being "hidden" by the mapping. Due to two reasons: - mappings across domains could hide employer changes, - even the "mapped-to" (i.e. "new") address may not be up-to-date. Stewards may be able ACK typo fixes and simple name order changes even in the absence of the affected (historical) contributor, but cross-domain mappings are not something they can ACK on their own. (At least this is my understanding from the meeting.) Personal note in the end: can we perhaps structure this patch set per email adress / "liveliness groups"? I think most people will ignore a patch that has tens of CC's, even if their personal ACK is needed for it. On the other hand, if we have 60-100 patches, but each patch is just emailed to 2-3 people (and any given person only gets a very low number of personal patch emails), such a series has a better chance at succeeding. (We could even commit such a set piece-meal -- commit the most recently ACKed subset every week or every two weeks.) Just some speculation on my part. Thanks! Laszlo