Date: Thu, 28 Jan 2021 08:06:55 -0700 From: Warner Losh <imp@bsdimp.com> To: Mark Millard <marklmi@yahoo.com> Cc: Milan Obuch <freebsd-git@dino.sk>, freebsd-git <freebsd-git@freebsd.org> Subject: Re: git setup/usage question Message-ID: <CANCZdfp%2BFj0BKympunpwwXzp4VRzp2ETb=2UWoeDBGn4zE8=HA@mail.gmail.com> In-Reply-To: <1F06D4FA-D3B0-4B25-AC99-14A0F31C2ABF@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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Jan 28, 2021 at 2:45 AM Mark Millard via freebsd-git < freebsd-git@freebsd.org> wrote: > > > On 2021-Jan-27, at 22:33, Milan Obuch <freebsd-git@dino.sk> wrote: > >>>> . . . > >> > >> 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. > I experimented with bare and hated it. I have about 30 in-flight patches, most of them trivial. Doing this for a few years, I've found the following: 1. worktrees are great for long-term things. So I have a work tree for stable/12 and main and occasionally for big projects. 2. 30 small branches with 1 change is better than 1 branch with 30 changes. As crazy as it sounds, it's easier to manage, especially when waiting for reviews. 3. It's much better to switch branches often and practice good hygiene by committing all changes. 4. Commit early, commit often, rebase frequently to curate the changes as you go. 5. Keep changes small. 6. Get the basics into review early, especially ones that are surprising. I make liberal use of git cherry-pick to move patches from branch to branch if I notice something while working on something else. I rebase to reorder and reorganize patches. I keep changes small and as independent as possible. There's no advantage to --bare for my workflow. When I tried it, I wound up with more complexity without any benefit. Same when I over-used worktrees. For me, there was more benefit from having lots of small branches and always keeping a clean tree. I avoided stash, though it's closer to mercurial's mq workflow I used to love (unpushed patches tend to go stale quickly). These are among the reasons I've left the lots of work trees and/or using a bare repo stuff undocumented: IMHO it just adds complexity and confusion for the vast majority of users w/o there being much benefit. People can extrapolate from what's documented should they have special needs. Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfp%2BFj0BKympunpwwXzp4VRzp2ETb=2UWoeDBGn4zE8=HA>