a ports developer daily git workflow

[Adriaan de Groot]

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]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.freebsd.org/pipermail/freebsd-git/attachments/20190531/a1cfe3ee/attachment.sig>