From owner-freebsd-git@freebsd.org Thu Jan 28 10:09:03 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 5A6C54FEAD6 for ; Thu, 28 Jan 2021 10:09:03 +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 4DRGQk2CXmz4sm9 for ; Thu, 28 Jan 2021 10:09:01 +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:08:59 +0100 id 00F577D9.60128D3B.00017A5D Date: Thu, 28 Jan 2021 11:08:57 +0100 From: Milan Obuch To: Mark Millard Cc: freebsd-git@freebsd.org Subject: Re: git setup/usage question Message-ID: <20210128110857.0ff1db28@zeta.dino.sk> In-Reply-To: <1F06D4FA-D3B0-4B25-AC99-14A0F31C2ABF@yahoo.com> 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> 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: 4DRGQk2CXmz4sm9 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:09:03 -0000 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. > >> 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. > > 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. That's all for now. Back to some work... Regards, Milan