From owner-freebsd-git@freebsd.org Thu Jan 28 10:29:00 2021 Return-Path: Delivered-To: freebsd-git@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 165F94FF2AA for ; Thu, 28 Jan 2021 10:29:00 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic306-19.consmr.mail.gq1.yahoo.com (sonic306-19.consmr.mail.gq1.yahoo.com [98.137.68.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4DRGsl1RPmz4v29 for ; Thu, 28 Jan 2021 10:28:58 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1611829737; bh=1STgcyN1OJOnbtJA+YCLa4hNt907916Z53Nynv558Le=; h=Subject:From:Date:To:From:Subject:Reply-To; b=S6ssl4g1p0j3hBSOrad0G3WXO/ZuUAU1nalXafPl2IYGsEUNuRzSuG253LV24tj1wQok+HN2pk2og756G1kesaopvTKKqTEMkFxim/v7MAQSQFLofGtkSpz7kA18GrL7CbbYPEA/8vok9m93FboZqPiGCKRx4f3nFR27oTYXkOXs+1MMBtU66OegSGtdJQPa2pnGgjXxYjkEPyBpsr/CDtgkrFpuvl1O2l2d4rPifTx/y1Csqz0tIU4YXrq81uXRRvAAmIE+NyutWILyTvIP+rQ3AHtUt8k6WBihr+6w9myr0/pHyaZgDBMh6gG7jB9E92rbGhRGNrIt2Uw4HL9Oqw== X-YMail-OSG: 2Q4TaGIVM1mOI1f1d5UVqbOsXQyp5JlHrijw0YkDLI1YWiZHWSwIjiYnEg5gwlI qymCKdc9yYR.Cbi.ow7BGgRZys5n8zjkxshw5RHyiNKXGizLPE795eNp06f3iCInepOu6QUHOK8r U1FPcOtnB8dtso875V.oc1hAEQvj63JsGIENobd.ujvXfxYiNnlJTVHiwA0_2cTTJdh.ZOylJ4L9 pLunG_wmPyaIaYtsTEn23PvLF2deVnXUU.gj8LFGVqKjSCl8Vr8Pv6qbaFTMFbaM4s9ytFqMy38l dHF2NKfU_DB_jOyWfF7_0E5DoVUaPgIdB.xZeXzp8OnE4lR54SAJmwSzgveJ9EovsrOLgB4opKYq .gd.18o_IcCCVkbstDuUmtmfZsqCeBUPmSQSz.mVbZaT_rufFonLyktXT2m_EJr8z.Sa9IDzb6Mv aZME3Jem5QeKvNFl5LscE_TlSgjdvmLBezo587ShQsvzMtM2as5A.RPZdw6WsMaYSsUMtmOx6AFI y3.qi_ok2_6H2CIHVnBVdJzN7bMTFVxzUcgIwBoovb1nOVmrDC3VNwFrgRdhx6CM6mrrtXhD9jef CWk9LqDReKofS8Nol.WSf4v5qccfnx7eZ5ypZ.naGi186oOFquH9klv8w3yqhfyJYdVI7t_KgXo4 _UQmvPxFe66dchdUXDBjp5wimyHNqNJ_hltbCgWTvlUz3p3zJOS9EHuhPmv9VDDbcyoNkO4W.Yqz wsz2FSxqOIb_UPmi9ZnywPvqgftuwIrCq7dVyGXW8o0hOEOOvAKpKD5Cv3CS51hVsjhv5rKzISwU KzX8G.Nrj81Qk.YQaBmH0DpLxMAtBoLHo5OtCTqTdGGoeQ8dZ9.mXFxbxVF20i5oHrYYBI51PeMR sCUdcFYt2GthKK50LRmsV0bFZXsTi_3dZCjqwNO_CbIcbDycuoqxtIZ3h1USYL4qXvWUz9u7k17q Eh9yNtr_46Wthi747M.hPBovxnrRSiFf8SRMTNGXDsUZYLrWPwxd7.eywp67KqZUOyB9A0GcN1cg Hs2V26JKqhjQ1POk1XcIsRfqkhIe3tBgFhraTe6M20fqg_r4peGQvhzzSaKup1Wn4yPcZxoR_ozG r2OPCufgFK7gZsC3X.9UkfTAVHyAKbYHA9O3EdXAj6PuSLn5D5L7LCfdXaNc29Y6r976ffln..MM yYAIFs_u7OF8jfsDEyx3KON9JOQ2I.KXtSpfgbyb3FFqIrBRiLKA05ilvE9o2zWvJlnO_0aDIqku S30Vsh8MI5OHnvuszs9IR.96_gg9T8WneXW4bJuRV1RJaH9fskWF8Vu.ERSCEO9F80ggNWhP8WQs BZXV_MRTTLUFcgRU4IPb72M3bqfuUsib.UkVh3iawPN3CrxFYk9FRh8HUZ3nKjcw3qcMlFjrsrI4 kx8dH8jszqkLGUzpYxjsOmoGlamSYpWrklwnO7zws1DWeAMDyUj134Afg4LNukSmY7d0lSeHvhQt rt0a6.ZPT8MTWl90u_TtwvRq0xFtANZEuc13JUlZ1IrBnRJLcO9YT45C9wlCGGgAUZjxM2.43Kzb Icguq2P9b25o0NJ1OZt6oCdt6j_cYRcTrp1bnhsmSLb.8Ua5rBgWXYV6sCE6fH93E5l_.n1OHILL d_a_y.ajfuR0xA23dy6iWnEhnTWENJOyvRdtCtQVOMptBI7DG9x4n3iAtbZn3RYNSIrZR1Coinj. CNe1Xk3fW4T8JcVeXf7j9gCi08Rdo6VZRwOqPSOqU53HMxsIxQrBEdRheuKquS6_MmrB87bf7_RO .x8pbt5tM49Dk1Suclx1HH5Eiue7L1Nci43LZuUwY72c.d29qBt79YxWA8Tug49zLwGNZGIM7_.i fT3VpUUxELAsdTMfsyyV0_19Yt3AYlF5ExY.kZ3YHL9bIQgSkAx_hZeQDDxEv8BAGb.dzR_zF9BY IzYNN122QBdF5LC5sD1SxgCaKpOmU.TyswPx_v7z_AvCO99AFv2fbQdbCO2SmNTH5LcwIuHp6pmV GALddsXXNT6ONoit3adpgMZaSsD4.kzX7c84Lx6GH7eXAO_G41vHX2ZSZMSxa6FtPSm3VgkYnnG5 FNs6KPEaJkKB05uLnC9r.AOSZO3WQ_1eLPqzB.6TUd7sP.Uf6sp4LlT6R69CYXkXx1wa4oaHvYsT 1n89Ppn32oqBibr7xjnSahw3lIkMOikf69LEtCu_xj5YiMqHZxxVkx860vbmtoqIrirdK.DyiUoS mD8R.75wBvqPGPu0Vid7dddUCC.pSjjRZ.78qXs0P8nKYaps9UbX52GTw.8vUjngv7ZzeuAHaW9Z xMCSSntI55c_1NeZOVHCS65CJ31MqUlhmqderKgN5.vT6uvfk.9IsZ5BLL7Ivhw_oWtfs99cWHHK CoU8nhMWbnOfvZkH_TPEfz6zFEZlqIrLWDt4D3.MA97Mz3XDqx0Lhodo1rd6J_Ryt.TSBc8QR5jC tCKYZnj1yv5KYsJnmylW9JX0llPFMRHYVip35w6KGvZmDFI0gATtNq3ykjg-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Thu, 28 Jan 2021 10:28:57 +0000 Received: by smtp412.mail.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 40d7c838bbdd9f144b5ee953ce4900ae; Thu, 28 Jan 2021 10:28:53 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Subject: Re: git setup/usage question From: Mark Millard In-Reply-To: <20210128110857.0ff1db28@zeta.dino.sk> Date: Thu, 28 Jan 2021 02:28:51 -0800 Cc: freebsd-git@freebsd.org Content-Transfer-Encoding: 7bit Message-Id: References: <20210126151017.4a9dd711@zeta.dino.sk> <00F58366-4178-458E-8865-E1A2E5324EB4@yahoo.com> <20210128073315.44377b29@zeta.dino.sk> <1F06D4FA-D3B0-4B25-AC99-14A0F31C2ABF@yahoo.com> <20210128110857.0ff1db28@zeta.dino.sk> To: Milan Obuch X-Mailer: Apple Mail (2.3654.40.0.2.32) X-Rspamd-Queue-Id: 4DRGsl1RPmz4v29 X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.50 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[98.137.68.82:from]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; SPAMHAUS_ZRD(0.00)[98.137.68.82:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.82:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.82:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-git] X-BeenThere: freebsd-git@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussion of git use in the FreeBSD project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2021 10:29:00 -0000 On 2021-Jan-28, at 02:08, Milan Obuch wrote: > On Thu, 28 Jan 2021 01:44:48 -0800, Mark Millard > wrote: > >> On 2021-Jan-27, at 22:33, Milan Obuch wrote: >> >>>> . . . >>> >>> With some tweaks, things are perfectly working now, for me >>> everything is perfectly logical. Actually I would describe it as >>> expected for using multiple worktrees, not vasting space (keeping >>> multiple full repositories) and time (updating multiple >>> repositories). >> >> FYI: I have only one .git/ and multiple worktrees, but I did not >> use --bare . One worktree is the (implicit) primary one in the >> directory that contains the only .git/ . The other worktrees I >> added after the initial clone. >> > > ... so currently we are using basically the same setup, I just have no > implicit worktree, I created main worktree explicitly. Functionally it > is totally equivalent, just with small, cosmetic, difference I can > place my main worktree anywhere in file system. > >> In other words, I did what Warner suggested and documents >> for that aspect, although using my own naming conventions. >> >> I never use the same branch in more than one worktree. >> All the worktrees automatically find the .git/ . And >> from the .git/ materials git can also find the >> worktrees for the branches that have such. >> > > I saw an article on this subject suggesting basically you can work on > more unrelated things in parallel. Think of developing new feature in > one worktree and creating another worktree for working on quick fix > needed for coping with some catastrophic failure, which must be done > asap. You need not to think how you should save your work, just switch > into relevant worktree and do it. > > I see another usefull case - working on a feature, which requires for > some reason worktree remaining unchanged for some extended period of > time. I can still follow development in another worktree for the same > branch without disturbing work done elsewhere. Worktrees are basically > independent on each other. > >> I do fetch and the --ff merge separately. I use the --ff >> style so that if at some point it can not do a fast-forward >> it will report that and not do something else. Without the >> --ff , if such a mess-up happens, then it will instead do >> something else. In other words: I have it validate the >> expected type of context actually exists. (Paranoia >> coverage.) >> > > We do not disagree here. Actually git-merge man page tells --ff is the > default, --no-ff being used in some special case. I could be wrong, but > to me it looks mentioned special case does not occur when tracking > stable branch. If, however, something bad happens, I can still throw > away damaged worktree and create new one from scratch. The branch in the .git/ would be "damaged". The problem would not be limited to a worktree's separate directory tree. (Unless one uses --no-commit on the merge, I guess.) >>>> It looks to me like he is using a configuration (--bare) >>>> outside the range FreeBSD is intending to deal with and >>>> so he needs his own fairly-unique procedures for using >>>> git for FreeBSD activity. >>> >>> >>> I think exactly the opposite - the way I did it looks (at least to >>> me) as a natural way extending simple case described in Warner's >>> Git Primer if one desires to track multiple branches for whatever >>> reason. >> >> FYI: Warner documented using worktrees without using --bare >> for the FreeBSD git context and stated that he would not >> document --bare use. I tried what he documented and it >> worked just fine for my use. >> > > As far as I tested for now, the only difference between standard and > --bare usage is no implicit repository and (main) worktree linkage. > There may be something else there not discovered yet, but my ongoing > testing seems to confirm this is actually the case. You indicated earlier that --bare disallowed --origin use. I used the -o freebsd in my clone and have such an origin. I can use instructions/documentation that presumes the normal origin configuration --and do so "as is" in the instructions. >>> I am still fine tuning my setup and gaining more experiences with >>> git, but in my oppinion (and others as well, I found some articles >>> mentioning exactly the same) worktrees are really powerfull tool >>> for a developer, which, when used with some thinking and carefully, >>> could make one's development much easier. >> >> I am using worktrees. But I am not using --bare . So far as >> I know, any differences are tied to that distinction. >> >>> I plan to document my setup soon with simple steps to re-create it >>> and some explanations as well. I do not still understand everything >>> in detail, but what I tried makes me confident I can use git this >>> way effectively. >>> >> >> Cool. Sounds like you and David W. may be providing some >> support for folks that want to use --bare (examples of >> a couple of ways of using git with --bare for FreeBSD). >> > > If anybody would like to try something and think they could use my > help, just ask. I am far from git expert, but as I was forced to use > git now, I found it actually be easy to use and logically built. > > I am not happy with dependencies required by our git port, or, more > exactly, with number of dependencies (some time in past this stopped me > from trying when I saw all the ports required to use git). I'd like to > keep port count minimal, but sometimes it just does not work this way. I use devel/git@lite to avoid a bunch of dependencies that I do not need. There is also devel/git@tiny that I've not tried. For reference: OPTIONS_RADIO_PCRE_VERSION= PCRE PCRE2 OPTIONS_DEFINE= GUI SVN GITWEB CONTRIB P4 CVS HTMLDOCS PERL ICONV CURL \ SEND_EMAIL NLS SUBTREE . . . .if ${FLAVOR:U} == gui OPTIONS_SLAVE+= GUI .elif ${FLAVOR:U} == lite OPTIONS_EXCLUDE= GUI SVN GITWEB CONTRIB P4 CVS PERL .elif ${FLAVOR:U} == tiny OPTIONS_EXCLUDE:= ${OPTIONS_DEFINE:NCURL} ${OPTIONS_RADIO_PCRE_VERSION} OPTIONS_SLAVE= CURL .endif === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)