git setup/usage question

[Mark Millard]

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 at lite to avoid a bunch of dependencies that I do
not need. There is also devel/git at 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)