From nobody Tue Jan 23 14:51:32 2024 X-Original-To: freebsd-git@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TK99k35QJz56yVD for ; Tue, 23 Jan 2024 14:55:06 +0000 (UTC) (envelope-from naddy@mips.inka.de) Received: from mail.inka.de (mail.inka.de [IPv6:2a04:c9c7:0:1073:217:a4ff:fe3b:e77c]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4TK99j4R7Dz4VLT for ; Tue, 23 Jan 2024 14:55:05 +0000 (UTC) (envelope-from naddy@mips.inka.de) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of naddy@mips.inka.de has no SPF policy when checking 2a04:c9c7:0:1073:217:a4ff:fe3b:e77c) smtp.mailfrom=naddy@mips.inka.de Received: from mips.inka.de (naddy@[127.0.0.1]) by mail.inka.de with uucp (rmailwrap 0.5) id 1rSIB6-00D4To-Cs; Tue, 23 Jan 2024 15:55:04 +0100 Received: from lorvorc.mips.inka.de (localhost [127.0.0.1]) by lorvorc.mips.inka.de (8.17.1/8.17.1) with ESMTP id 40NEpWQa018167 for ; Tue, 23 Jan 2024 15:51:32 +0100 (CET) (envelope-from naddy@lorvorc.mips.inka.de) Received: (from naddy@localhost) by lorvorc.mips.inka.de (8.17.1/8.17.1/Submit) id 40NEpWeA018166 for freebsd-git@freebsd.org; Tue, 23 Jan 2024 15:51:32 +0100 (CET) (envelope-from naddy) Date: Tue, 23 Jan 2024 15:51:32 +0100 From: Christian Weisgerber To: freebsd-git@freebsd.org Subject: Force merge conflicts? Message-ID: List-Id: Discussion of git use in the FreeBSD project List-Archive: https://lists.freebsd.org/archives/freebsd-git List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-git@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spamd-Bar: - X-Spamd-Result: default: False [-1.10 / 15.00]; AUTH_NA(1.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; MIME_GOOD(-0.10)[text/plain]; MID_RHS_MATCH_FROMTLD(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:202113, ipnet:2a04:c9c7::/32, country:DE]; MIME_TRACE(0.00)[0:+]; FREEFALL_USER(0.00)[naddy]; MISSING_XM_UA(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; MLMMJ_DEST(0.00)[freebsd-git@freebsd.org]; ARC_NA(0.00)[]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; R_DKIM_NA(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-git@freebsd.org]; DMARC_NA(0.00)[inka.de]; R_SPF_NA(0.00)[no SPF record] X-Rspamd-Queue-Id: 4TK99j4R7Dz4VLT Say, you create a branch of the ports tree to work on something that touches a number of ports (like arrowd@'s current autotools-mandir project). You accumulate changes and bump PORTREVISION in various port Makefiles. Meanwhile work on the "main" branch continues and PORTREVISION also gets bumped for entirely different reasons. Now when you rebase/merge your changes into "main", git is happy that the PORTREVISION line is the same in both branches and silently unifies this. Unfortunately, your incoming changes should _increment_ PORTREVISION, but that increment is now silently lost. Is there a way to tell git to create a conflict when two branches have the same change? -- Christian "naddy" Weisgerber naddy@mips.inka.de