From owner-freebsd-git@freebsd.org Fri May 31 14:23:55 2019 Return-Path: Delivered-To: freebsd-git@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1013B15BE7AA for ; Fri, 31 May 2019 14:23:55 +0000 (UTC) (envelope-from adridg@freebsd.org) Received: from lb1-smtp-cloud8.xs4all.net (lb1-smtp-cloud8.xs4all.net [194.109.24.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.xs4all.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 59D826E9C8 for ; Fri, 31 May 2019 14:23:54 +0000 (UTC) (envelope-from adridg@freebsd.org) Received: from beastie.bionicmutton.org ([62.251.92.29]) by smtp-cloud8.xs4all.net with ESMTP id WiQghCuIl0YQeWiQhhIg8b; Fri, 31 May 2019 16:22:47 +0200 From: Adriaan de Groot To: freebsd-git@freebsd.org Subject: Re: a ports developer daily git workflow Date: Fri, 31 May 2019 16:22:46 +0200 Message-ID: <5307387.XOh7uYVVfo@beastie.bionicmutton.org> Organization: FreeBSD In-Reply-To: <33d1a353-a3ee-465d-9cb7-8e31e6ccf73e@www.fastmail.com> References: <33d1a353-a3ee-465d-9cb7-8e31e6ccf73e@www.fastmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2497415.ffieBuXMo3"; micalg="pgp-sha256"; protocol="application/pgp-signature" X-CMAE-Envelope: MS4wfBQVqRROkijdzjg13bZgag1LDmPECUgosS541O7+XM+4SbEozDqzj3HfS+Ip+phHhLBVMwErV3u+UGyd+VTjDlJfuQHkO5LJluIvLPnY3QvHLrPvyjx5 obtBw2C64cdILxXGBHU4Ub32oSwH6eq60Zxqn6K4xZA0TEmw4R1MSELHlBpVvh256s606O/l4CsK/A== X-Rspamd-Queue-Id: 59D826E9C8 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.97 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; NEURAL_HAM_SHORT(-0.97)[-0.975,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; ASN(0.00)[asn:3265, ipnet:194.109.0.0/16, country:NL] X-BeenThere: freebsd-git@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of git use in the FreeBSD project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2019 14:23:55 -0000 --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--