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 in > > git. > > 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. Thanks for the reply Adriann. This is a good point - what happens with svn if we *both* update 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 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 clean 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 > 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. 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 –global pull.rebase true Or omit the global and do it per-repo. > For git-using folk, "git fetch ; git rebase origin/master" is the known > solution, and push will yield a linear history. Correct; I think in practise actual conflicts just with this will be a very rare occurrence. My gut feel says we should try this and see how often it occurs, before trying to engineer it away. > Depending on muscle memory and branching discipline, the many-diamonds problem > 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 problem > *could* be documented out of existence, possibly with some tools on the server > side to help enforce linear ports history. I agree. https://devblog.nestoria.com/post/98892582763/maintaining-a-consistent-linear-history-for-git has an example of that sort of tooling, and a nice alternative explanation of merge commits. https://help.github.com/en/articles/support-for-subversion-clients may be of interest to people - try it against https://github.com/freebsd/freebsd-ports A+ Dave
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9842b51f-9c0d-4a81-b862-003c05a0bc3d>