From nobody Tue Sep 16 02:37:08 2025 X-Original-To: freebsd-current@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 4cQmJg4pd1z684hv for ; Tue, 16 Sep 2025 02:37:23 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic305-21.consmr.mail.gq1.yahoo.com (sonic305-21.consmr.mail.gq1.yahoo.com [98.137.64.84]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4cQmJg25w0z43L3 for ; Tue, 16 Sep 2025 02:37:23 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1757990240; bh=WFUpAEdH98rtDE817BSWeHCe8q3MCvQlnyxcegIm4Rc=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=k9AciQ6deVPoTRqCizqozp1uQLovZsVh0HnnOybLoaJkjXiUzJzA18ERMAcReb9k2c0kXqK7EzwBjjDV0SfdYVVyoVqqx57vpgS2GUgDgTsn+wu2IlHB1E3ySBuI0SZtfiuEQGrf9rzikO3K2cDv/Qohzq7heifmgdj6S0cGwynNr4NjoY393r1cQQrQn11OcR6LSG73IfF3fN3T74xU/5gjaly8oRA+fo6BQJhVLEry+x1nHC2fjgpZToaRoNd1G59GrdP59n8Ulg1QpfbLwJdUklzpi6OtDmPaOL3wtsuNnQxtUDKbMEf7i4tY01yE/sV8IvbKVxAAycujC6DBCQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1757990240; bh=+XZ0dlnrqjInWPwdcPHV8X3TW0B6E0u2waftQ8o6G8t=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=eb1/wPa+01saKTYyWOPwfZ4KoZke8Rbruphf3IRsT/gfXRQen0sJq34FkOXS4YrkOh+CHvGRDDMqykQ5xNSPPm0nplDVkzbzizTyw4WTIV5LpOSs1z6EbXUhg1dWfWNE1iiqEQQMCcpekuadp5JYSjEbxZH1EVf+WgHtSU4H6CSymCf8D/oATD9/Bwjm56sIt9VdGBiC0OMutPE6IEPTUtK2yZ17KR2LD0yJV8HbK5m55Af7nsfOt09JSfFinCaOjrz0oXCmodqXujOYeVx3OHcQfUWS59V79F0rzgOv+Yob5BXkz4bdrMALhoTfEHDfvhs9dAN94y8CTvj5raDQfQ== X-YMail-OSG: JxMqoAsVM1k75D7sOL1S4zdmFu4QSmsoXPQxpcMSYOEqNsqPDRADSeZwDjkdVyR USj46HSyVf6SFUbIiqsJDmyhZygUbRiwcqPDf5xq027tFAzzR44ANvA31zNg9W6PzjzfefQLxBAX vd8HNRcP6V.G.w9EXltlXfv7dqvtwNynyXOjvkq088WCOLPEqB7fvcfNx0Wm5F1o387o0SHDjbiD t8oB4agFFUSfJ.fcxWfa9lJI3rqiIlPBeGQ6uXTGPoU_7.iBHgjOoWbD4lKcjKx6CizFw.UHn64i JLDCY0dP58WFq7INa069qzALYiBC01Pd7fi2ySvTInNS028xUn5KJH13iNAM2WoUWM2HUNV4zFbV Jwjt7vraTDp4UJBorovAI2waUs5tMAgaKpq5krNw_UKFnNe2H3B.YIXTkNYjUb5kM6z8xnFeH4pQ fXnRaHT9y.FfVmM8r10UNzERFbpYw1ms2yV_7F9PhXf34Jbob3Th90CE8zz4LrjkgGi1Zo33MVod IVkw_g3btYI8SOTZIfqWo3j6tZQzZt0d7O5BIt0qvhrGbgHeF9LEP7zA2zDY0X3jf_1Fnxuh56sS q_Oi4n0GHSfTledWzdCWNO_I6F.DcPa1omGXBiHynto8AMGEmEweXFlwLwKFDBmWTUY8akKlkvfv nQv8uWAJ0Z6hnJHsyXlG5RgfQh_jF_VkSLcfNgi.SQXW1.0oPox3.uLSoVRRBO1UNv86MiR95Pu2 IZ9IKrLn_YHz6H8J09A6mx6dZBJhl5knRCAvzS0RVEyJtzT_.fmoACC_HSVUhex.JU5iCUYtnyiu wVGsf55FZCuqgS5g7DPPWDKE8DmvVEHs4C8Xw88x4rDr.0C7ygeFd4rhta9JdB6N4njG24vh4ymc yuAMRTw3GmwLFFli7nlG1wSzhdVqWMNXBxT.pY5JOL1nbl3316q55cHFvf6QgBkYb0PZO_y_sF5H gJ57hJXgf1LXM1vVbrnQUvU_W8LNXWCJ1ojmP0o8_D4Qo3vCh8gNbhG_J4mPKT3Qrn3JeBUI4IMn 8sp8U1hJ7x5gw9TXWRZhDoU2IBQnr4P9WbZy2EJ3Li45hw9ARrSArIrUM6BO6x.KpGToBAE0IgVr qNVA5ptF69BqxZN06FUZyGTlYZ7RQklmsUF7GKXJVXpX0PsgHpU.I8iEL62AnXxItvEgekx1fKoI 1udFCrpZQmoV3Ie.fBXXLf8yMTUCgHhP6RuYP8ffTQ_GSJkObG8wVQT7uWk2zrj8qTxppogQUbyM _eQ7V5ru_xMFX9ZCkwXDxdrV7RKVef8bbq_iWXUzrQ1z8Q.qAbNrMfsl3LFQmeLgUpjyHuCGASwo rKhFVfvqjDxuNDC_1kVNB.Rhhb8xtpajCGyZg.PuTOcE55UvQSjWJ.YselyMNFxIVJKJWjQYV5V2 rM4gmyCjQGMpEliNcR8i1ZLgyB_lJm4P.xGTmaBnIUHxrn7gBjBAyncpaGE278AB8Hl3jPbXH2Ad AxMCiQkP8C39tpP0mNOVWpUhW.r3KFR.h_jhgslishukaQZWKlWL8FoTlAC_17sXIIFK3p0ICSKF Z.4uWNYDDSh3uaH7ylwt6IJl8rC6X2otEticFVI1EskbVEpnrExKi3j_CMgBbLGnWtla54.PxajF NOpWP8sbPUzduxel_j28VtDpCwTMLo.6U.ViR5zKbN3_jPRuyC0p_aCrArYLGDMDxX5HNbvx8FuJ Z2NejCGE4YuFvvXsXuKGzAIK7.yQUTuX6C8Nt4CF.hws9ddkxL2pDY9bqZoJ6L6cYBd8LD7QH6nW emyoNSlgbK4fDoEemsQ9wp_L2Lh5asoab7wYH08VdjFyyG3g1nw2ox_yu2W54BKBC90VELzFGR5T Llf0fC3jepmYI7nSbSsP8rUu53RYOc6ofojYyKB.rg4tjlyf1wNa2WeqbMBkD6xexd2E2J6zI6SP 5QolJQ3PcNWCQ1Mdjv3f8rFfGuem.nQhkiuWg9eSZEOP3HGaCHygv5M_F8E6mkBILfK7WlRgUBzv RlgGCS3x_ZW9kAePmpEbYNoWCGTzUfBvDSC6mHKolo_SsSO8HqQVsjDpZhDvD87ajh7n5UwXSXFj 5_SF2IQehY.FZvvSfblwci3EjjhROM4eRK9jXmMkkzIOkq3UasjWC6eXbxcdY8KOcxaZNQyMf55s jeDvi5ttrMHN48IIMl_C4itu.J8k.ytDLxvn22dD40HFdVZnWPjlAdQWVbgbpVn2StPmlGgqd80M 6RXZSL7O36Rv8WIKiyUGWIoth9S2wc7dWj8IZy2n.8GZA5UBLpZ8JcOS2emcZ8kNFuLc.G2JwtL6 s X-Sonic-MF: X-Sonic-ID: 8434ad79-0dcc-4d95-951e-da53f938b1c0 Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Tue, 16 Sep 2025 02:37:20 +0000 Received: by hermes--production-gq1-7bfc77444d-llcgf (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 97d7d349b0f80bb8086bd42cd7abd1af; Tue, 16 Sep 2025 02:37:19 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.700.81\)) Subject: Re: Git and buildworld running at the same time From: Mark Millard In-Reply-To: Date: Mon, 15 Sep 2025 19:37:08 -0700 Cc: FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <1098032E-D574-4F52-979D-27F96D677C93@yahoo.com> References: To: bob prohaska X-Mailer: Apple Mail (2.3826.700.81) X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4cQmJg25w0z43L3 On Sep 15, 2025, at 18:48, bob prohaska wrote: > On Sun, Sep 14, 2025 at 10:01:54PM -0700, Mark Millard wrote: >>=20 >> May be things got out of place? 505 MB of RES and >> 1.3 GB for SIZE? (The values would be consistent.) >=20 > Yes, likely I mixed numbers and labels 8-( >=20 >>> thinking SIZE was total memory and RES was in ram. In >>> hindsight, I've no evidence for that interpretation. >>>=20 >>>>> If I gather correctly, it looks like at times, when it >>>>> will be a notable time before activity like building >>>>> software, something like: >>>>>=20 >>>>> git -C /usr/src/ gc --no-detach --auto >>>>>=20 >>>>> would be appropriate. The "--no-detach" avoids it >>>>> running in the background so you know when it is >>>>> running vs. when it finishes. You would want to do >>>>> this often enough to avoid fetch/merge --ff-only >>>>> or pull from doing such automatically or having >>>>> a lot of accumulated pending work to do. >>>>>=20 >>>=20 >>> Knowing that a git pull will be followed by some >>> background work it isn't really a problem. I was >>> fooled into starting buildworld before git finished, >>> now I know enough to let it finish. However, for a >>> script the --no-detach is a useful addition, at >>> least when confident git will finish successfully. >>=20 >> --no-detach and --detach are not "git pull" >> command line options but are "git pc" command "git gc", not "git pc". Sorry. >> line options. >>=20 >> maintenance.autoDetach can control the behavior >> of commands that do not have --no-detach and >> --detach command line operations. If unset, >> then gc.autoDetach controls such (if set). >> If both are unset it is as if they had been >> set to true (so: detach). >>=20 >>>=20 >>>>> There is: >>>>>=20 >>>>> gc.autoDetach >>>>> Make git gc --auto return immediately and run in the = background if >>>>> the system supports it. Default is true. This config = variable acts as >>>>> a fallback in case maintenance.autoDetach is not set. >>>>>=20 >>>>> and also: >>>>>=20 >>>>> maintenance.autoDetach >>>>> Many Git commands trigger automatic maintenance after they = have >>>>> written data into the repository. This boolean config option = controls >>>>> whether this automatic maintenance shall happen in the = foreground or >>>>> whether the maintenance process shall detach and continue to = run in >>>>> the background. >>>>>=20 >>>>> If unset, the value of gc.autoDetach is used as a fallback. = Defaults >>>>> to true if both are unset, meaning that the maintenance = process will >>>>> detach. >>>>>=20 >>>>> So you can force it to not detach automatically. >>>>> But, then, you might have a long wait for the >>>>> command that added data to complete: >>>>>=20 >>>>> # git -C /usr/src/ config maintenance.autoDetach false >>>>> # git -C /usr/src/ config gc.autoDetach false >>>=20 >=20 > It's starting to sink in 8-)=20 > I've run the two commands above. So, in the case of a command like > git pull > pull.log && buildworld > build.log & > can I expect buildworld won't start before git is finished? That is what you should expect. FYI: The global settings can be viewed via the likes of: # git config list The settings that apply to a specific place like /usr/src/ can be viewed via the likes of: # git -C /usr/src/ config list That last likely also lists the same as the first, unless there has been a /usr/src/ specific alternate setting made. [ /usr/src/.git here is either the repository content's directory tree or a worktree's .git file identifying where to find such. ] So you should be able to confirm that the settings show up when you specify the -C /usr/src/ sort of path. I will note that typos like # git -C /usr/ config list will produce the global list if a valid path is found (that does not have a .git directory/file for the repository). # git -C /NO_SUCH_PLACE/ config list would instead complain about: "No such file or directory" > If > not then I'm really confused..... >=20 >>=20 >> Part of the question would be if you want to >> have to remember to provide the --no-detach >> vs. if you want it to be automatic. >>=20 > In this case automatic --no-detach is likely better. > Buildworld on a Pi takes days, an hour here or there > matters relatively little. =3D=3D=3D Mark Millard marklmi at yahoo.com