Date: Thu, 25 Jun 2020 20:33:47 +0200 From: Adriaan de Groot <adridg@freebsd.org> To: freebsd-git@freebsd.org Subject: Re: svn primer translation to git Message-ID: <5295692.8gLySxXtyI@beastie.bionicmutton.org> In-Reply-To: <CANCZdfow92K_a-60VyzhkkCMg7MjXfJz1zwSisGTT1qdTCD31g@mail.gmail.com> References: <CAPyFy2Dy4cLQpgUsk_ushXsQFvRPk2S8SEfgWF=0xibGRGJvKw@mail.gmail.com> <20200625171314.GB75705@spindle.one-eyed-alien.net> <CANCZdfow92K_a-60VyzhkkCMg7MjXfJz1zwSisGTT1qdTCD31g@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--nextPart4824989.YNO7O01DYZ Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="utf-8" On Thursday, 25 June 2020 19:47:24 CEST Warner Losh wrote: > > One practice I've not adopted that we may want to recommend (especially > > if we're going to have pre-commit scripts for people to install) is to > > make your origin use a read-only url so you have to make an explicit > > push to (e.g.) a freebsd remote. At least at the beginning when it > > appears we're going to be allowing direct commit, that's a way to > > limit foot shooting. > > I almost always do a git show for each and every commit I push. The few > times I've tried to short cut this, I've wound up in trouble. Something else to explicitly discourage is fast-cycle "git commit -a ; git push" which I've seen some people do in other projects: it mimics the svn approach of "when you commit it goes to the central repo immediately" but misses all the useful bits of a DVCS -- the ones Warner just mentioned, of rewriting local history and making the branch or sequence of commits logical and well-documented in commit messages. This might sound a little Linussy, but maybe we should for a while offer "git intermediates" where act like the Linux staging trees / lieutenants who gate things through to the primary repository. That can help alleviate friction when people start pushing their own stuff. Oh, and I should mention the KDE setup of GitLab, too: - merges in the real repository *socially* require a review and merge by someone else (this can also be done technically, but that's a GitLab enterprise feature) - pushes to normal branches are ok (this is where some MRs come from) but you can't force-push - branches called work/ are .. work branches, and force-pushes are ok there. This approach means that you can coach people on their work branches, before merging them in to the primary branch with whatever strategy you like. It slows down *some* things, just a little bit, (nice when it's a footcannon) and helps people up the git learning curve. [ade] --nextPart4824989.YNO7O01DYZ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQGzBAABCAAdFiEEV+FL0c1sGYvBG/GNYafSYnfk0NsFAl707gsACgkQYafSYnfk 0NtzcQwAp6pAJAKCAyHXpHzAgjkgfQBf27SiJIT3ivCV72MfJmhu4LESRdGZmwOf 2kKZ2w2YlP2HfnNF39ar6fA/INUV4K0oP7FlBUvD124oKwuwmpKjzCBcl9gxtKmO JBAMBDipmGe6jwR70kqKl5mYpALsmemvKwG3PmEAAuY0ChCFkrL5eWiS46mXsPy5 n/ldKUFhtFc67s63pRzo84HBvvTxZXx81LZGWhCJCXttxLcI8T8mJiIkIgz9FZw+ 5nJwbXEyCG7D2t/ytDDI1/MGDFx+qqH3UBBkQnhl+yLtGAyOT6N3jXEaEDSoD1De /XzvnnjWeTX972o+JPi8+D+j/1uvJEyWW+6mOC7d64QmPFW+PDJxn29ACE+KwFFp dI1zevIXu2ZvBMtdNePyudN0Ff4oq14GsIe8p3pIAUl793c9BAzgCbmFNKvA0DtK 7gtsQAvlyl7A7FlJd5FdYYxTOzaS0uRO0NhnXXQFYLSzeOdeBuAjeu5K5KNUrPeq BnG/hHk0 =Fo7Q -----END PGP SIGNATURE----- --nextPart4824989.YNO7O01DYZ--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5295692.8gLySxXtyI>