From owner-freebsd-git@freebsd.org Sat Jun 1 17:12:26 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 C25E615C193C for ; Sat, 1 Jun 2019 17:12:26 +0000 (UTC) (envelope-from dch@skunkwerks.at) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C13C96FF2E for ; Sat, 1 Jun 2019 17:12:24 +0000 (UTC) (envelope-from dch@skunkwerks.at) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id B2E4B22033 for ; Sat, 1 Jun 2019 13:12:17 -0400 (EDT) Received: from imap6 ([10.202.2.56]) by compute7.internal (MEProxy); Sat, 01 Jun 2019 13:12:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=skunkwerks.at; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type:content-transfer-encoding; s=fm2; bh=lPjzn NKPwEjpAHco/SDh84SP9IZ2OuIdHfygJ9xaQDw=; b=BoVkQDw7WzXLZBDpohbCu X0OYPljwJ5+/sDwByMRrQ8VPBszXfX93P/FIERfkWD5Hpan8KZTtcVuNi+n648LN YpYTZl/04hUQSlz/i3uStwpdvJErjkYLegWiTosJSE3Nlpw2/yIV559YDndRm6Jj bKcvlgXfrGldr2WC38lYOcTxDZQXKxv6QeEXKwYea+SPJR1qKXPPfmHDnIbrOdKd luIfo3f8atPS8x+GerBA3ReNQ1aZt1VMrRM635DFtdzvi7lsLaxRKRbbsomjC55F LDbnaIsfY+RrKeyK0Oxthfb8d76ZxaBgmXHFBFvIYw1cGmUctVB9/yhyo2geHLoy g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=lPjznNKPwEjpAHco/SDh84SP9IZ2OuIdHfygJ9xaQ Dw=; b=7XbFgy6BJIKz+6xmWuqSnx8lvs4Ihd/jV925a114eJgjrskFkLjj3AfV/ oWSWak6kjvFW0ATbTkicqWjgIiwy7mY5cdk4vcGQ8AwGhtkpEO7ZMRKbZp0UVBlO p68KHTAGz7ienhfYTurAAlz+FZfWdgcJTDlmtATOwSM9FvU+ssHR0cM5nDmrVO86 QUnmyCaW1Yh9noxyuvyrYo51QE0KIOhRSRPMBVfb+9cSmWAEg5v/LOMRE0g8VrZ9 vfBv4Q+TCzfL2wxMbS556cAfbYW98iHZJ564su6r8Vb69smt3LHB1unVnbd1Yn4S 6jljQRIKY2f/OijRBP9VcXAQA8nrg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrudeffedgudduvdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgfgse htqhertderreejnecuhfhrohhmpedfffgrvhgvucevohhtthhlvghhuhgsvghrfdcuoegu tghhsehskhhunhhkfigvrhhkshdrrghtqeenucffohhmrghinhepghhithhhuhgsrdgtoh hmpdhnvghsthhorhhirgdrtghomhenucfrrghrrghmpehmrghilhhfrhhomhepuggthhes shhkuhhnkhifvghrkhhsrdgrthenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 69EC21400A0; Sat, 1 Jun 2019 13:12:16 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-555-g49357e1-fmstable-20190528v2 Mime-Version: 1.0 Message-Id: <9842b51f-9c0d-4a81-b862-003c05a0bc3d@www.fastmail.com> In-Reply-To: <5307387.XOh7uYVVfo@beastie.bionicmutton.org> References: <33d1a353-a3ee-465d-9cb7-8e31e6ccf73e@www.fastmail.com> <5307387.XOh7uYVVfo@beastie.bionicmutton.org> Date: Sat, 01 Jun 2019 17:12:15 +0000 From: "Dave Cottlehuber" To: freebsd-git@freebsd.org Subject: Re: a ports developer daily git workflow Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: C13C96FF2E X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=skunkwerks.at header.s=fm2 header.b=BoVkQDw7; dkim=pass header.d=messagingengine.com header.s=fm2 header.b=7XbFgy6B; spf=pass (mx1.freebsd.org: domain of dch@skunkwerks.at designates 66.111.4.28 as permitted sender) smtp.mailfrom=dch@skunkwerks.at X-Spamd-Result: default: False [-6.10 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[skunkwerks.at:s=fm2,messagingengine.com:s=fm2]; XM_UA_NO_VERSION(0.01)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:66.111.4.28]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-git@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCVD_COUNT_THREE(0.00)[4]; DMARC_NA(0.00)[skunkwerks.at]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[skunkwerks.at:+,messagingengine.com:+]; MX_GOOD(-0.01)[in2-smtp.messagingengine.com,in1-smtp.messagingengine.com,in2-smtp.messagingengine.com,in1-smtp.messagingengine.com,in2-smtp.messagingengine.com,in1-smtp.messagingengine.com,in2-smtp.messagingengine.com,in1-smtp.messagingengine.com,in2-smtp.messagingengine.com,in1-smtp.messagingengine.com,in2-smtp.messagingengine.com,in1-smtp.messagingengine.com]; NEURAL_HAM_SHORT(-0.97)[-0.967,0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:11403, ipnet:66.111.4.0/24, country:US]; IP_SCORE(-3.53)[ip: (-9.76), ipnet: 66.111.4.0/24(-4.68), asn: 11403(-3.15), country: US(-0.06)]; MID_RHS_WWW(0.50)[]; RCVD_IN_DNSWL_LOW(-0.10)[28.4.111.66.list.dnswl.org : 127.0.5.1] 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: Sat, 01 Jun 2019 17:12:27 -0000 On Fri, 31 May 2019, at 14:24, Adriaan de Groot wrote: > 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 i= n > > git. >=20 > The thing with ports is that there's rarely long-lived branches unless= you're=20 > updating a bunch of ports at once that all hang together (e.g. KDE Fra= meworks=20 > plus their dependencies **might** qualify). Most of the time, you have= a=20 > modified Makefile, pkd-plist and distinfo and that's it. You want to p= ush that=20 > to the central ports tree. >=20 > Here's the scenario I'm afraid of, and given the volume of ports commi= ts (ok,=20 > fine, it's probably no more than two hundred a day) it might happen of= ten=20 > enough to be annoying: >=20 > - 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 ser= ver. > - I have one extra cup of coffee, pou-build, and push. >=20 > My push is rejected, because the remote repo contains work I don't hav= e. Drat.=20 > One important thing is that your *unrelated* work has changed the tree= and=20 > blocked my commit. With SVN that doesn't happen (er .. ?) because it's= file- > oriented. Thanks for the reply Adriann. This is a good point - what happens with svn if we *both* update=20 ports/devel/Makefile to add dodgy1 and dodgy2? Presumably it rejects the commit? In svn if there's no conflicting changes then "stuff just works". In git, a merge will take care of this for you also, the patch is=20 almost always localised enough for git to figure out what's needed. However, I am assuming that -- at least initially while people get more comfortable -- merge commits are either forbidden, or restricted to a group like re@. Note that it's possible to let the server do the rebase & then make a cl= ean fast-forward series of commits - this is what github provides in a nice = little rebase+merge button, and there is some tooling to help with this too like https://github.com/max630/git-push-update =20 > If I naively do "git pull" I'll get a tiny diamond merge: A is a paren= t of my=20 > commit, and my commit and B are parents of the merge. I could try to p= ush=20 > that. Doing so will result in large numbers of tiny diamonds. If I spe= nd too=20 > much time cursing the tools, you might have fixed misc/unrelated in th= e=20 > meantime, getting hash C on the server, and I'll have to do the merge-= dance=20 > again, getting another diamond. I was part of the first community at the ASF to move our repos from svn = to git and I don't recall ever seeing this in practice. FreeBSD is a bigger= development group so we'd need to take more care. I'd also expect given our svn heritage that we'll want a linear history = too, in which case merge commits are forbidden, and people should be advised to set automatic rebase-on-pull on for their repos to avoid your diamond= merge of hell pattern: git config =E2=80=93global pull.rebase true Or omit the global and do it per-repo. > For git-using folk, "git fetch ; git rebase origin/master" is the know= n=20 > solution, and push will yield a linear history. Correct; I think in practise actual conflicts just with this will be a v= ery rare occurrence. My gut feel says we should try this and see how often it occ= urs, before trying to engineer it away. > Depending on muscle memory and branching discipline, the many-diamonds= problem=20 > could seriously annoy people. It would annoy **me**. Also, but I think above is sufficient most of the time. This could well be different in svn branches in src, compared to ports though. > .. now that I've written it down like this, it strikes me that this pr= oblem=20 > *could* be documented out of existence, possibly with some tools on th= e server=20 > side to help enforce linear ports history. I agree. https://devblog.nestoria.com/post/98892582763/maintaining-a-consistent-l= inear-history-for-git has an example of that sort of tooling, and a nice alternative explanati= on of merge commits. https://help.github.com/en/articles/support-for-subversion-clients may b= e of interest to people - try it against https://github.com/freebsd/freebsd-p= orts A+ Dave