Date: Tue, 1 Dec 2020 09:36:48 -0700 From: Warner Losh <imp@bsdimp.com> To: Rene Ladan <rene@freebsd.org> Cc: Chris Rees <crees@freebsd.org>, Adam Weinberger <adamw@adamw.org>, git@freebsd.org, "portmgr@FreeBSD.org" <portmgr@freebsd.org> Subject: Re: converting rmport to git Message-ID: <CANCZdfrMP--yZBedSoCBhAFuDzhxLt3BbNi=DCoErrXTtY=qtg@mail.gmail.com> In-Reply-To: <20201201095906.GA50345@freefall.freebsd.org> References: <20201129164707.GA31739@freefall.freebsd.org> <CAP7rwchHsz3x4v%2BWmxEqTyXOvJx6fUbRuKnirBPEPVzz7gMw0A@mail.gmail.com> <14871125-A032-4980-8DB1-0210E34D5A11@FreeBSD.org> <20201130105337.GA42359@freefall.freebsd.org> <7246FB00-655B-4BD4-BC99-B87E4595969C@FreeBSD.org> <20201201095906.GA50345@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Dec 1, 2020 at 2:59 AM Rene Ladan <rene@freebsd.org> wrote: > On Mon, Nov 30, 2020 at 08:19:40PM +0000, Chris Rees wrote: > > > > > > On 30 November 2020 10:53:37 GMT, Rene Ladan <rene@freebsd.org> wrote: > > >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@adamw.org> > > >wrote: > > >> >On Sun, Nov 29, 2020 at 9:47 AM Rene Ladan <rene@freebsd.org> wrote= : > > >> >> > > >> >> Hello, > > >> >> > > >> >> I started converting some scripts in the port tree to git, and hi= t > > >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=C3=A9) 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? > > > > Well... I don't think git actually does git cp properly does it? As in= , > doesn't it cleverly work it out for itself? > Git only knows about mv, not cp :( > I also think that git mv is just a convenience for git rm and git add.... > > > > The only reason I wrote the removed ports thing is because we were > losing the link between old and new version when a port was removed and > readded. Is git likely to DTRT without it? > I don't know, perhaps we can search the git history itself. > The typical way I've seen this done is to add the metadata to either the 'bring it back' commit (so like our MFC After: lines), or using the 'notes' feature in some way. The upside to either of these techniques is that you preserve the data. the downside is that neither is known by git log. I've also seen weird merge commits attempted for this since git log knows about them... The only problem is they are sufficiently weird that git log does odd things for everybody across them... I don't anticipate that git will do the right thing w/o help because the ports tree has so many nearly identical files. For simple ports, the Makefile could have been copied from anywhere, likewise some of the pkg* files. Though for simple ones, lost history doesn't lose much that's useful. For complex ones, it likely would do close to the right thing since complex ports, kinda by definition, are different. Though I'd test this notion (because as I'm typing this I find myself making too many mental reservations)... To be honest, though, I think this is an area where some experimentation to understand the alternatives is needed because this use case is relatively rare in the larger open source community. Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfrMP--yZBedSoCBhAFuDzhxLt3BbNi=DCoErrXTtY=qtg>