converting rmport to git

[Ulrich Spörlein]

On Tue, 2020-12-01 at 09:36:48 -0700, Warner Losh wrote:
>On Tue, Dec 1, 2020 at 2:59 AM Rene Ladan <rene at freebsd.org> wrote:
>> On Mon, Nov 30, 2020 at 08:19:40PM +0000, Chris Rees wrote:
>> > 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.

Isn't the ports copy or move fixable by doing it in 2 steps? That is, 
one commit is copying or moving the file without any modification inside 
the file whatsoever (sic!). This is obviously a bogus state for the 
ports tree, so a 2nd commit then changes the content of that new file to 
adjust its name or category or whatever.

The good thing about a DVCS is that these 2 commits will obviously be 
pushed together, atomically, so no one will ever see the broken 
intermediate state. Unless of course you want to `git bisect` stuff, so 
it's not a panacea and also brittle as it depends on a human doing the 
right thing.

Cheers
Uli