Date: Fri, 31 May 2019 16:22:46 +0200 From: Adriaan de Groot <adridg@freebsd.org> To: freebsd-git@freebsd.org Subject: Re: a ports developer daily git workflow Message-ID: <5307387.XOh7uYVVfo@beastie.bionicmutton.org> In-Reply-To: <33d1a353-a3ee-465d-9cb7-8e31e6ccf73e@www.fastmail.com> References: <33d1a353-a3ee-465d-9cb7-8e31e6ccf73e@www.fastmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--nextPart2497415.ffieBuXMo3 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="utf-8" On Friday, 31 May 2019 11:59:01 CEST Dave Cottlehuber wrote: > Below is my day-to-day workflow for dealing with ports and patches in > git. There is a lot of similarity between your workflow and how the KDE-FreeBSD team manages its ports (see e.g. https://community.kde.org/FreeBSD/Setup/Area51 ). One thing, though, is that we end up pushing to SVN in the end and that linearizes history and handles the rough edges around file-based commits vs tree-based commits for us. Because of those rough edges, I'd really like to have separate discussions about src/ workflow, and ports/ workflow. I don't do any FreeBSD src/ work, so I'd like to talk about ports. The thing with ports is that there's rarely long-lived branches unless you're updating a bunch of ports at once that all hang together (e.g. KDE Frameworks plus their dependencies **might** qualify). Most of the time, you have a modified Makefile, pkd-plist and distinfo and that's it. You want to push that to the central ports tree. Here's the scenario I'm afraid of, and given the volume of ports commits (ok, fine, it's probably no more than two hundred a day) it might happen often enough to be annoying: - you and I both clone ports repo at hash A (master, at 9am). - you update devel/dodgy, while I do devel/kf5-dodgy. - you commit, pou-build, and push. You get hash B recorded on the server. - I have one extra cup of coffee, pou-build, and push. My push is rejected, because the remote repo contains work I don't have. Drat. One important thing is that your *unrelated* work has changed the tree and blocked my commit. With SVN that doesn't happen (er .. ?) because it's file- oriented. If I naively do "git pull" I'll get a tiny diamond merge: A is a parent of my commit, and my commit and B are parents of the merge. I could try to push that. Doing so will result in large numbers of tiny diamonds. If I spend too much time cursing the tools, you might have fixed misc/unrelated in the meantime, getting hash C on the server, and I'll have to do the merge-dance again, getting another diamond. For git-using folk, "git fetch ; git rebase origin/master" is the known solution, and push will yield a linear history. Depending on muscle memory and branching discipline, the many-diamonds problem could seriously annoy people. It would annoy **me**. .. now that I've written it down like this, it strikes me that this problem *could* be documented out of existence, possibly with some tools on the server side to help enforce linear ports history. [ade] --nextPart2497415.ffieBuXMo3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iHUEABEIAB0WIQTVFBoRsP760fy+Jisy7lRaPghTTwUCXPE4tgAKCRAy7lRaPghT TyadAQCzQscbeAOXfBw66KxzH0IYPuybZPGHqlly90YecJM+NQD+NsU+2StZwZCA Lq/8TGg0yIMT2w6V+v4+Uv1CujWNrMQ= =QdSQ -----END PGP SIGNATURE----- --nextPart2497415.ffieBuXMo3--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5307387.XOh7uYVVfo>