Date: Thu, 28 Jan 2021 02:28:51 -0800 From: Mark Millard <marklmi@yahoo.com> To: Milan Obuch <freebsd-git@dino.sk> Cc: freebsd-git@freebsd.org Subject: Re: git setup/usage question Message-ID: <B8E0C6D7-CCE2-4A8D-8249-140A326DAD98@yahoo.com> In-Reply-To: <20210128110857.0ff1db28@zeta.dino.sk> References: <20210126151017.4a9dd711@zeta.dino.sk> <YBHTTg9mMYSRsPKO@acme.spoerlein.net> <00F58366-4178-458E-8865-E1A2E5324EB4@yahoo.com> <20210128073315.44377b29@zeta.dino.sk> <1F06D4FA-D3B0-4B25-AC99-14A0F31C2ABF@yahoo.com> <20210128110857.0ff1db28@zeta.dino.sk>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2021-Jan-28, at 02:08, Milan Obuch <freebsd-git at dino.sk> wrote: > On Thu, 28 Jan 2021 01:44:48 -0800, Mark Millard <marklmi at yahoo.com> > wrote: > >> On 2021-Jan-27, at 22:33, Milan Obuch <freebsd-git at dino.sk> 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)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?B8E0C6D7-CCE2-4A8D-8249-140A326DAD98>