From nobody Wed Dec 8 21:33:31 2021 X-Original-To: freebsd-doc@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 317FA18E5863; Wed, 8 Dec 2021 21:33:48 +0000 (UTC) (envelope-from yetoohappy@gmail.com) Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (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 4J8Vlw0dNkz3rVC; Wed, 8 Dec 2021 21:33:48 +0000 (UTC) (envelope-from yetoohappy@gmail.com) Received: by mail-lf1-x130.google.com with SMTP id n12so8266886lfe.1; Wed, 08 Dec 2021 13:33:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WDlQl/AYUQzhE3zaHYFhiZZcChwEiQTpo55VP40eQ8c=; b=F5oHWW2Ka3i5UK8Jww78x1vV3fDHqKpVCAeys6DdG4fxr5elPMaW0k2b5Z2jyUOVMQ DgKCry+OCwdUkFQv/5bAeVtCyxIT3o/8t3hWIOXM+P18FrvD/A0lRxRAa9Ws6dSZMPS8 SOP7B3CMrnrMACnuOhnWbxe4dFGQxbJ2uh82r9oh45km63hEpdEbdqSeY/QmjEvuM5sm V5jV/9xOBICoF/ZBXXrZbBY+bf4MgZwZ35C+3hsReNBxLnBssotZj/d0hpojVHmspuw9 wMLk7w3URYI/u/VGVa/HciU5WPmsh05OosgyWltURrEDtVhyyX5qWNXCfqq0QRykoOlC NCEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WDlQl/AYUQzhE3zaHYFhiZZcChwEiQTpo55VP40eQ8c=; b=4y5HirWeMWY0Ug2DmeEGuPvdM8lq4XrlKdQ14L1Q9Au92Hhgn+RQ1smq93nZ/sWgMj K/75nQCOXNFAXIoTI1lkTIOhbWFKhzap+WhbS47YQPqtLi3l9Gkvmv28keg2s5VH3yyC JBkryopQuCA8iCCBxULqOHoUPMRkL0HbdJYpM5iGZOW4s0CRE3f/BDeD5jmT1gdCoitE vkCJJZSFoXu5EX4nUxA6IKu3jug1Fo/gdhfbPwnpmYWCVrr1d6PU88Rf/Ck7fDO9vVXo jgDjM5/6+VhlgrkpugrzvzHL+bpDSfqU0GvwFKx9E92Zgko9FnNioWHmx4Hse9BcLFz4 Oauw== X-Gm-Message-State: AOAM532V5OBP5hIGkP5eyv9pMWwpO9sVuoZb4brEirK1nSg3i8mWegFP u2qxuzdl/WDL/yab4eX47BLv5HnmpGqJwr2tZaBwwDvLMbQ= X-Google-Smtp-Source: ABdhPJzU9Xnh+OfAs9hdY5+/G0GHnHPTd4zXiswEA4+nmWNuirt/hWV8l9C+dWtLQVmdiN01jxPcQCyWB/FJJX3lEmg= X-Received: by 2002:a05:6512:1304:: with SMTP id x4mr1951779lfu.484.1638999226855; Wed, 08 Dec 2021 13:33:46 -0800 (PST) List-Id: Documentation project List-Archive: https://lists.freebsd.org/archives/freebsd-doc List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-doc@freebsd.org MIME-Version: 1.0 References: <56a60a9b-3d7f-b29e-6074-71078f4b0fe6@quip.cz> <2e894793-f860-3415-1f5d-26fd5e85a69d@FreeBSD.org> In-Reply-To: <2e894793-f860-3415-1f5d-26fd5e85a69d@FreeBSD.org> From: Yetoo Happy Date: Wed, 8 Dec 2021 13:33:31 -0800 Message-ID: Subject: Re: Make etcupdate bootstrap requirement due to previous mergemaster usage more clear in handbook To: John Baldwin Cc: Miroslav Lachman <000.fbsd@quip.cz>, freebsd-doc@freebsd.org, freebsd-current@freebsd.org Content-Type: multipart/alternative; boundary="000000000000b4361105d2a93e92" X-Rspamd-Queue-Id: 4J8Vlw0dNkz3rVC X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: Y --000000000000b4361105d2a93e92 Content-Type: text/plain; charset="UTF-8" If it was in a temporary directory, even if I manaually resolved the file and merge, I was expecting that file marked as resolve to stay in that temporary directory until I was done with all my files. Maybe I'm confusing mergemaster -Ui behavior with something else, but it seems like only merging after the user has reviewed all manual changes in a final verification sweep is common sense or at least explicitly display the tree directory that would be written to and say this is final change. I didn't know that each file etcupdate went over was going to be the final review. I think my system broke by the time I got to the rest of the postponed items due to this. On Wed, Dec 8, 2021, 9:05 AM John Baldwin wrote: > On 12/3/21 4:58 AM, Miroslav Lachman wrote: > > So beside the update of documentation I really would like to see some > > changes to etcupdate workflow where files are modified in temporary > > location and moved to destination only if they do not contain any syntax > > breaking changes like <<<<, ====, >>>>. > > This is what etcupdate does, so I'm a bit confused why you are getting > merge markers in /etc. When an automated 3-way merge doesn't work due > to conflicts, the file with the conflicts is saved in > /var/db/etcupdate/conflicts/. It is only copied to /etc when you > mark it as fully resolved when running 'etcupdate resolve'. Perhaps > you had multiple conflicts in a modified file and when editing the file > you only fixed the first one and then marked it as resolved at the > prompt? Even in that case etcupdate explicitly prompts you a second time > after you say "r" with "File still has conflicts, are you sure?", > so it will only install a file to /etc with those changes if you have > explicitly confirmed you want it. > > -- > John Baldwin > --000000000000b4361105d2a93e92--