converting rmport to git

Rene Ladan rene at
Mon Nov 30 10:53:37 UTC 2020

On Sun, Nov 29, 2020 at 11:26:41PM +0000, Chris Rees wrote:
> Hey,
> On 29 November 2020 17:12:21 GMT, Adam Weinberger <adamw at> wrote:
> >On Sun, Nov 29, 2020 at 9:47 AM Rene Ladan <rene at> wrote:
> >>
> >> Hello,
> >>
> >> I started converting some scripts in the port tree to git, and hit a
> >design
> >> decision with Tools/scripts/rmport.
> >>
> >> 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.
> >
> >Git uses topic branches for not-clobbering-the-tree purposes, so your
> >proposal below seems like the git analogue of an svn sparse 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
> >
> >If our users will have to install git from ports or pkg, is there much
> >concern that people won't be on a reasonably recent version of git?
> Nah, we can just check the version and complain easily.
> >> 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
> >
> >That definitely seems more consistent with the git workflow. Create a
> >topic branch, do the thing, merge the branch, push the change.
> Looks like a great idea.  I'm starting to get used to git, but I'm happy if you (René) want to push ahead with this, as I'm sure my approach would be dreadful....
OK, I'll rewrite the script to use the branch workflow. This does assume
having an existing clone of the git repository present, but I guess that
is a safe assumption if you are a ports committer :)

The addport and mfh scripts could use a similar workflow. Speaking of
addport, it uses your website to check if a port pre-existed, that website
should learn about git too?


More information about the freebsd-git mailing list