From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: master updated (18e7bc87521 -> c71a520d1da) Date: Wed, 09 Aug 2023 14:59:11 +0300 Message-ID: <834jl8mnow.fsf@gnu.org> References: <169136956945.2149.648813436805504636@vcs2.savannah.gnu.org> <87wmy737ld.fsf@yahoo.com> <87leen37gk.fsf@yahoo.com> <87pm3w8vye.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="23644"; mail-complaints-to="usenet@ciao.gmane.io" Cc: stefankangas@gmail.com, luangruo@yahoo.com, emacs-devel@gnu.org To: Robert Pluim Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Aug 09 13:59:21 2023 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qThqS-0005xf-24 for ged-emacs-devel@m.gmane-mx.org; Wed, 09 Aug 2023 13:59:20 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qThpx-0007mZ-G1; Wed, 09 Aug 2023 07:58:49 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qThpv-0007mJ-H3 for emacs-devel@gnu.org; Wed, 09 Aug 2023 07:58:47 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qThpv-0001cl-8N; Wed, 09 Aug 2023 07:58:47 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=3SIq2AvtlLbcS5X+Y1hSYHwo4hW/z3ALaaW0j4p0F5s=; b=msSN0kjExaxfzEFHEvt0 N29f5sLrxBz9ZBF6wQocTpQaNnyg6+x/mSmm+R39oeihd6+YO1wNVUSjtSvLeKmoffK0dnGtir6BM 8qDUL5b2BG5TvZGWqNER4BF8m+tPx9V+ZMLw5bC1XCL0CdH+wW/lyMzIm5fFxzqueRr2P9iA7xUuF kbgzm5UCRHASgMVkWvCPAbO4agVsK7HPnRFFFeSBiTTWZCYMxQqo+AOlfUIXj0zmFMp5aKG4aiQQy 68MGdruJ0/Uax2xau7n3LL+WMFsLgf+3uZH1bTqsfhZY7j5UfXtJnO8Q2QQjR8MKHSrp4v24ozlVd dUjKTTHo974P6Q==; In-Reply-To: <87pm3w8vye.fsf@gmail.com> (message from Robert Pluim on Wed, 09 Aug 2023 10:24:25 +0200) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:308468 Archived-At: > From: Robert Pluim > Cc: Po Lu , emacs-devel@gnu.org > Date: Wed, 09 Aug 2023 10:24:25 +0200 > > Stefan> In admin/notes/repo we have this advice: > > Stefan> In general, when working on some feature in a separate branch, it is > Stefan> preferable not to merge from master until you are done with the > Stefan> feature. > > Which is why you should rebase in that situation, but some people > donʼt like rebase for reasons that I donʼt quite understand. "It was > slightly broken in a version of git from a decade ago" is not a valid > argument: emacs developers should be expected to update their > tools. > > Stefan> Perhaps we could expand it with some advice that would be more > Stefan> directly applicable to long-living and "large" feature branches (such > Stefan> as android and nativecomp), where postponing the merge until the end > Stefan> might be impractical. > > See my previous paragraph. There's no reason to rebase (although if someone wants that, they can do it). The preferred workflow for feature branches is to merge from master only once, just before you are going to land the feature. Then test the results of the merge as well as possible, and merge back. The usual reason that people merge from master is because they are afraid of master breaking their feature or afraid of merge conflicts. But these dangers are quite illusory, and if one works on a feature that is completely new (as in this case), neither of the two dangers is real.