From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 110368 invoked by alias); 20 Jan 2020 14:13:20 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 110353 invoked by uid 89); 20 Jan 2020 14:13:19 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy=personal, HContent-Transfer-Encoding:8bit X-HELO: gate.crashing.org Received: from gate.crashing.org (HELO gate.crashing.org) (63.228.1.57) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 20 Jan 2020 14:13:09 +0000 Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id 00KED5TY031163; Mon, 20 Jan 2020 08:13:05 -0600 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 00KED5KD031162; Mon, 20 Jan 2020 08:13:05 -0600 Date: Mon, 20 Jan 2020 18:42:00 -0000 From: Segher Boessenkool To: Julien _FrnchFrgg_ Rivaud Cc: gcc@gcc.gnu.org Subject: Re: gcc-cvs mails for personal/vendor branches for merge commits Message-ID: <20200120141305.GZ3191@gate.crashing.org> References: <20200115141617.GS10088@tucnak> <014947f3-43a8-e54d-8798-5d5f104e1fbd@redhat.com> <89C87961-B21A-4E54-914F-40A89B5D5BBD@googlemail.com> <20200118174945.GT3191@gate.crashing.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.2.3i X-IsSubscribed: yes X-SW-Source: 2020-01/txt/msg00365.txt.bz2 [ Please do reply to me when you reply to my mails. Maybe gmane did that? Yet Another reason not to use gmane. ] On Sat, Jan 18, 2020 at 11:04:12PM +0100, Julien _FrnchFrgg_ Rivaud wrote: > Le 18/01/2020 à 18:49, Segher Boessenkool a écrit : > >If a branch does rebase all people who commit to it need to make sure > >not to overwrite others' work. Your pushes are always non-fast-forward, > >so you do not notice you did not incorporate someone else's new work if > >you do not take care. > > There is the git push --force-with-lease option to avoid that. Its goal > is to force a non-fast-forward push, but only if the remote position > (HEAD) is actually where you expect it to, that is no work you don't > know about has been pushed in the mean time. > > I strongly recommend to use --force-with-lease on non-user branches. > User branches you usually control totally and are the only one to push > to, so that's less an issue. Sure, that option helps to avoid problems when you do the wrong thing. But you still need a plan what to do when there *are* problems, or to avoid such problems in the first place. You need some policy for when the branch is rebased, and who does that, and how the other users are supposed to learn about this. (Using merges avoids this, it always makes a mess, instead it postpones all the "make it a clean patch series" work to later.) Segher