From owner-freebsd-git@freebsd.org Thu Jan 28 10:45:27 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 E02934FFFF6 for ; Thu, 28 Jan 2021 10:45:27 +0000 (UTC) (envelope-from freebsd-git@dino.sk) Received: from mailhost.netlabit.sk (mailhost.netlabit.sk [84.245.65.72]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4DRHDl1CF5z3BmL for ; Thu, 28 Jan 2021 10:45:26 +0000 (UTC) (envelope-from freebsd-git@dino.sk) Received: from zeta.dino.sk (fw3.dino.sk [84.245.95.254]) (AUTH: LOGIN milan) by mailhost.netlabit.sk with ESMTPA; Thu, 28 Jan 2021 11:45:24 +0100 id 00F404E3.601295C4.0001834E Date: Thu, 28 Jan 2021 11:45:22 +0100 From: Milan Obuch To: Mark Millard Cc: freebsd-git@freebsd.org Subject: Re: git setup/usage question Message-ID: <20210128114522.2f2beadd@zeta.dino.sk> In-Reply-To: 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> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.33; i386-portbld-freebsd11.4) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4DRHDl1CF5z3BmL X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of freebsd-git@dino.sk designates 84.245.65.72 as permitted sender) smtp.mailfrom=freebsd-git@dino.sk X-Spamd-Result: default: False [-3.30 / 15.00]; RCVD_TLS_LAST(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[dino.sk]; RBL_DBL_DONT_QUERY_IPS(0.00)[84.245.65.72:from]; SPAMHAUS_ZRD(0.00)[84.245.65.72:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FREEMAIL_TO(0.00)[yahoo.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:5578, ipnet:84.245.64.0/18, country:SK]; 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:45:27 -0000 On Thu, 28 Jan 2021 02:28:51 -0800, Mark Millard wrote: > On 2021-Jan-28, at 02:08, Milan Obuch wrote: > > > On Thu, 28 Jan 2021 01:44:48 -0800, Mark Millard > yahoo.com> wrote: [ snip ] > >> 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.) > We'll see. When you do not commit anything into repository for that branch, I can't think of such a possibility. For such case, change flow (propagation) is 'FreeBSD's git server' ->(git fetch)-> local bare repository ->(git merge)-> local worktree. As long as you do not commit anything for given branch, this is unidirectional. Still worst case scenarion would be throwing away whole repository and starting from scratch. I do not think of a disaster which would require this, short of hardware disk failure, but that's it. [ snip ] > >> 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. > Details covered in my setup description, yet to be published. I found a way to overcome this limitation as I tested how to achieve what I want. [ snip ] > >>> 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 > I'll try it some time later. Regards, Milan