a ports developer daily git workflow
Adriaan de Groot
adridg at freebsd.org
Fri May 31 14:23:55 UTC 2019
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
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-
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 228 bytes
Desc: This is a digitally signed message part.
More information about the freebsd-git