From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: [RFE] Migration to gitlab Date: Fri, 22 Mar 2019 15:44:38 +0200 Message-ID: <831s2zrpkp.fsf@gnu.org> References: <1552789070.5272.1@yandex.ru> <1552791707.5272.2@yandex.ru> <1552793646.5272.3@yandex.ru> <1552821396.21432.0@yandex.ru> <83imwhwf4x.fsf@gnu.org> <837ecvux2q.fsf@gnu.org> <9c7cf558-a2d3-951e-d6e1-31b3ad5900cf@yandex.ru> <1553250888.28810.2@yandex.ru> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="155083"; mail-complaints-to="usenet@blaine.gmane.org" Cc: theophilusx@gmail.com, emacs-devel@gnu.org, dgutov@yandex.ru To: Konstantin Kharlamov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Mar 22 14:54:37 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1h7Kd3-000e9g-1m for ged-emacs-devel@m.gmane.org; Fri, 22 Mar 2019 14:54:37 +0100 Original-Received: from localhost ([127.0.0.1]:57784 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h7Kd2-0003mk-35 for ged-emacs-devel@m.gmane.org; Fri, 22 Mar 2019 09:54:36 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:32858) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h7KTU-0004DS-KM for emacs-devel@gnu.org; Fri, 22 Mar 2019 09:44:45 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:42472) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h7KTT-0002wA-WF; Fri, 22 Mar 2019 09:44:44 -0400 Original-Received: from [176.228.60.248] (port=3212 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1h7KTT-0007AZ-6m; Fri, 22 Mar 2019 09:44:43 -0400 In-reply-to: <1553250888.28810.2@yandex.ru> (message from Konstantin Kharlamov on Fri, 22 Mar 2019 13:34:48 +0300) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:234564 Archived-At: > Date: Fri, 22 Mar 2019 13:34:48 +0300 > From: Konstantin Kharlamov > Cc: dgutov@yandex.ru, theophilusx@gmail.com, emacs-devel@gnu.org > > > There's no requirement in Emacs development to send patches in series, > > you can send a single patch for the entire changeset. then you will > > get only one notification. > > This is odd, why would I do that? You don't _have_ to. I'm saying that you _can_ if that makes things easier for you. > If somebody would squash 20 commits into just one, and sent me for > review, "break commits by functional" would be my very first > comment. You won't hear such comments here. This is not one of the projects to which you are used, this is Emacs. > How a reviewer supposed to give any useful comments besides > high-level stuff like "remove the commented out code there", if a > sigle patch does 20 functionally different changes? I was talking about a single changeset, i.e. a set of changes that fix a particular problem or introduce a particular single feature. The rules for deciding what should be in a single changeset and what should be split between several ones are unaffected by what I said; the point is that you can submit changes for a single changeset as a single patch. If you do submit a single coherent changeset, trust me and others here that we will be able to review it. It's not your problem as a submitter. OTOH, submitting in a single submission to a single bug report a patch series which constitute more than a single changeset _will_ get you responses saying to break that into several unrelated reports and series. > Furthermore: if such patch was commited, how other developers in the > future, while studying the git-log, are supposed to make any sense of > this commit? > > And how one supposed to git-bisect a regression with such a commit? We do that all the time. Many (most) of the contributors rebase their changes on the latest master anyway, so this has to be dealt with regardless of how you submit the patches. E.g., most of those who create public feature branches in the Emacs repository will rebase before landing the feature, thus making bisection inside the branch development very hard at best.