Date: Sat, 01 Jun 2019 17:12:15 +0000 From: "Dave Cottlehuber" <dch@skunkwerks.at> To: freebsd-git@freebsd.org Subject: Re: a ports developer daily git workflow 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9842b51f-9c0d-4a81-b862-003c05a0bc3d>