converting rmport to git

[Warner Losh]

On Sun, Nov 29, 2020 at 9:47 AM Rene Ladan <rene at freebsd.org> wrote:

> Hello,
>
> I started converting some scripts in the port tree to git, and hit a design
> decision with Tools/scripts/rmport.
>

Thanks Rene!


> In the current SVN world it checks out a sparse copy of the tree to work on
> (just LEGAL, MOVED, category/Makefile and the port directory itself) and
> commits from that copy. This has the advantage of not clobbering an
> existing
> work tree and indeed does not need a pre-existing checkout at all.
>

There's two approaches for this in the git world. First would be worktrees.
These are checkouts of the repo on different branches. It's not sparse, but
it's not terrible all things considered. It would most closely replicate
what you're trying to do, though at the cost of disk space. There's ways to
do partial checkouts, but I've not had good luck with them.

The second is to assume everybody is using branches in their main tree and
can move to a new temporary branch at any time (eg have the tool do nothing
in a dirty tree).


> I could try to replicate this with git, but it seems like partial checkouts
> (not to be confused with shallow checkouts) are a bit of an afterthought
> [1]
> and need reasonably recent versions of the git binary and protocol. An
> alternative would be to just create a temporary branch on an existing
> checkout, say rmport-$USER-$EPOCH, do the removal work there, merge that
> branch to main, remove the temporary branch and push the new main. This
> feels
> less cryptic to me. It might also allow for better handling of merge
> conflicts
> with MOVED in case that file gets updated by someone else and you are in
> the
> middle of a big removal (say Python 2.7). Currently such conflicts crash
> the
> script (no work is lost because the temporary checkout is left alone in
> that
> case).
>

That's not a bad idea. branches are cheap in git. they let you fully test
that you've not broken things, if you want, and can be rebased if there's a
mid-air collision while all this is in progress...


> What do you think? It looks like we can use a similar solution to the
> addport
> and perhaps mfh scripts.
>
> [1]
> https://unix.stackexchange.com/questions/233327/is-it-possible-to-clone-only-part-of-a-git-project


I think we'll want to have MFC/MFH scripts. One of the open items is the
exact form these will take so we can take an accurate census of commits
that could be merged. There's issues all over the place here that become
less troublesome if the MFC/MFH commit message is decorated in a
standardized way (or if standardized notes are used). It's unclear what to
do here and I suspect we'll have at least a short period of chaos on the
MFC front when viewed in the rear view mirror of whatever grows up to take
its place. git can do some of this today w/o help, but only if we
cherry-pick w/o modification. And that's unreasonable: we have to tweak
MFCs all the time, and there's a proud history in at least src of
collapsing several MFCs. I'm afraid I've not looked at the ports world to
know if these things are the same or not, but I suspect at least an
occasional tweak is needed for MFHs.

tl;dr: branch based solutions are likely the ticket here.

Warner