Date: Thu, 28 Jan 2021 11:45:22 +0100 From: Milan Obuch <freebsd-git@dino.sk> To: Mark Millard <marklmi@yahoo.com> Cc: freebsd-git@freebsd.org Subject: Re: git setup/usage question Message-ID: <20210128114522.2f2beadd@zeta.dino.sk> In-Reply-To: <B8E0C6D7-CCE2-4A8D-8249-140A326DAD98@yahoo.com> 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> <B8E0C6D7-CCE2-4A8D-8249-140A326DAD98@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 28 Jan 2021 02:28:51 -0800, Mark Millard <marklmi@yahoo.com>
wrote:
> 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:
[ 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20210128114522.2f2beadd>