From nobody Tue Jan 23 21:51:51 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 4TKLQq72yzz58DcJ for ; Tue, 23 Jan 2024 21:52:03 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TKLQq2cflz4p1w for ; Tue, 23 Jan 2024 21:52:03 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x52c.google.com with SMTP id 4fb4d7f45d1cf-55a90b2b554so3589727a12.1 for ; Tue, 23 Jan 2024 13:52:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1706046722; x=1706651522; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=jz15TVbOsX2+c37JIRDNUEhmlyUvqks0LFt31/N0UVc=; b=R4Orz/DOFUu7lH8gv/sMxUUS412cUWHKl1VBIr0f0Z3Phv3k+Zt5Hb7AUpJF47HC67 gVQifvOjEgLbf4lNCVewJla08WKX6JgpNmvvWWebB+lo1KZxnkUrc9VPlYXkjhdbDT+9 X/3VVqGAzK+msA9IAleN1l9cE9PS5AGOIzzwo6zhTIionWkXzI2VXaPphY4V7vrvvuoW dpD2u/5TJ54SivruqZjlx4febig997KUugb9ae1LhnHGcMvUtQA+LdMoDPs3cn4v0AuM YtMqkhBlGOcvqyz9GHWTU2+nF7AyQ0QKL3f9tTo2S0OL+qLw/Ap2Dlb/dFEfxrrSz8Ew gemg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706046722; x=1706651522; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=jz15TVbOsX2+c37JIRDNUEhmlyUvqks0LFt31/N0UVc=; b=nl7byehsYVctvWJ7/3FQwAcpFvbwjk9eu0zNIrv03KE4q32vD1BiFKN55dA3vUHiTv YFCIAoH9gDXUOzG9N1siBSE7ZQrJuQZhISjitxwh1Dp3LoXEX0vW3q5TZ6htfOdmcVez AqcwR/b9V8qH4UcXZpwB+BFOojqYOiMhwd/lifS+6P+59FbaxHINTB95aYG43gd5RVQV U9A6oX914UOKhQ+1K+N2RjipGiSM1UE61LlQ81wAji8WbwwoKUm4No9lksZXIb2VKpmr gp/Tw66Hl81SFyuv9gfm7oJkoWQrZYKWHu3/ohIebRFFrQHy8yHj9NQaXLudVnjlrCPo 2UCQ== X-Gm-Message-State: AOJu0YxXyP8e6NhXe7RvDQijhAk9buKo5lnm2f/8I9s9v/K0Drm1Eigt CFX84bDQxuQmdfC7PAgVEF9c8lxjir3SRiQCtf340xKzkVGviBNfmEFkwTgOnD6Wz0+COXJiQT6 Vs6gJYXVWUUfOLHovTkCNDra995x0THdcwEDojdX/ZjoGBb5zq5A= X-Google-Smtp-Source: AGHT+IFiDyEWroR/Ag37Ckak3ajYLAnTiXwdLQvfUhOLgu5OONTjC1ELRjznSjlWDhc111jiK3YtU6DaxmKK3Rh3lhs= X-Received: by 2002:a05:6402:50d3:b0:55c:7e63:38b1 with SMTP id h19-20020a05640250d300b0055c7e6338b1mr1247489edb.35.1706046721982; Tue, 23 Jan 2024 13:52:01 -0800 (PST) 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 References: In-Reply-To: From: Warner Losh Date: Tue, 23 Jan 2024 14:51:51 -0700 Message-ID: Subject: Re: Force merge conflicts? To: Mathieu Arnold Cc: Christian Weisgerber , freebsd-git@freebsd.org Content-Type: multipart/alternative; boundary="000000000000d594f2060fa3f43f" X-Rspamd-Queue-Id: 4TKLQq2cflz4p1w X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] --000000000000d594f2060fa3f43f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jan 23, 2024 at 11:20=E2=80=AFAM Mathieu Arnold w= rote: > On Tue, Jan 23, 2024 at 03:51:32PM +0100, Christian Weisgerber wrote: > > Is there a way to tell git to create a conflict when two branches > > have the same change? > > I had a look and Git conflicts' resolution does not seem to be able to > do that. For Git, when you merge two files that have the same change, > then it assumes that it is the same change and is happy with it. > > For the case you are talking about, I would either: > > - Defer the PORTREVISION bump to when the branch is ready to be merged, > and automate it with one of the scripts in Tools. > - Bump PORTREVISON and add a comment on the same line with, say, > `# TODO: remove me` so that it forces a conflict to arise and > mechanically remove them before merging. > Personally, I'd set PORTREVISION to 100 in the branch and merge often. Who says that the first bump has to be to 1? If you really want it to be the numerically next number, bump it each time there's a conflict, (so 101, 102, 103) then you can look for those > 100 and re-adjust. If this has been done before, start at 200, etc. Since there's nothing wrong with 100, though, you could do this and land it like that in the main tree. It's a different variation on the force a conflict ploy though Warner --000000000000d594f2060fa3f43f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Jan 23, 2024 at 11:20=E2=80= =AFAM Mathieu Arnold <mat@freebsd.org= > wrote:
= On Tue, Jan 23, 2024 at 03:51:32PM +0100, Christian Weisgerber wrote:
> Is there a way to tell git to create a conflict when two branches
> have the same change?

I had a look and Git conflicts' resolution does not seem to be able to<= br> do that. For Git, when you merge two files that have the same change,
then it assumes that it is the same change and is happy with it.

For the case you are talking about, I would either:

- Defer the PORTREVISION bump to when the branch is ready to be merged,
=C2=A0 and automate it with one of the scripts in Tools.
- Bump PORTREVISON and add a comment on the same line with, say,
=C2=A0 `# TODO: remove me` so that it forces a conflict to arise and
=C2=A0 mechanically remove them before merging.

Personally, I'd set PORTREVISION to 100 in the branch and merg= e often. Who says that
the first bump has to be to 1? If you real= ly want it to be the numerically next number, bump
it each time t= here's a conflict, (so 101, 102, 103) then you can look for those > = 100 and
re-adjust. If this has been done before, start at 200, et= c. Since there's nothing wrong with 100,
though, you could do= this and land it like that in the main tree.

= It's a different variation on the force a conflict ploy though

Warner
--000000000000d594f2060fa3f43f--