a ports developer daily git workflow

[Dave Cottlehuber]

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 at .

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