Add boneyard branch for obsolete content.

[fhgwright]

See README-boneyard.

The remaining diff is just the resurrected content.

[fhgwright]

@mascguy
This is only a draft because the PR mechanism can't be used to create a branch with this configuration. In fact, it doesn't appear that a PR can be used to create a new branch at all, since the target branch selection is based on existing branches (leading to the close/reopen above).

Your should be able to "merge" this by something like:

1. git fetch https://github.com/fhgwright/macports-legacy-support boneyard:boneyard
2. git push <your main repo ref> boneyard

Or maybe the latter needs to specify boneyard:boneyard; I'm not sure.

You could use a different local branch name if boneyard is in use. After the fetch/push, you can delete the local branch if desired.

Aside from the general new-branch issue, this branch configuration has two unusual but useful properties:

1. Instead of being created by forking off from master, it begins as an empty branch and brings in the master content via a merge commit. This has the advantage that, when following the history with the --first-parent option, the history stops at the branch origin instead of wandering off into the irrelevant weeds of old master commits.
2. Instead of beginning with the merge, it begins with an empty root commit, followed by the merge. This is to work around the problem that a commit range requires specifying the parent of the first commit of interest, but a root commit has no parent. Starting the branch with an empty root commit makes that root commit's commit ID the parent ID of the first commit with real content, allowing the latter to be included in a commit range. This could have been avoided if git accepted 0 as the parent of a root commit, but alas, it doesn't.

[mascguy]

Given that the repo is very locked-down for safety, it may not be possible to maintain a separate branch like this. But I'll have to test.

Alternatively, could we simply include them - similar to your disabled tests - in a top-level 'obsolete' directory?

[fhgwright]

@mascguy
I'd originally thought about using a separate directory, but using a separate branch seems cleaner. It's also easier to use, since merging the branch with the master branch puts the tests in the expected place, with no Makefile changes needed.

I'm not aware of the "locked-down" aspect (and the "Security" section of this repo is empty), though if it's just a list of allowed branches, that shouldn't be too hard to fix (with the appropriate access). As I mentioned, I don't think it's possible to create a new branch with a PR, but that has nothing to do with being "locked-down". You could just try the fetch/push and see what happens. And of course, after the fetch, you have the code in your own repo, where you can peruse it at will before pushing it.

The "disabled" directory isn't for disabled tests - it's for some code that implements a feature whose introduction apparently caused breakage. That was originally worked around by the uglier hack of having code in the Portfile to delete the bad source before building the port. Moving the code out of the source directory had the same effect without the ugly Portfile hack.

It was always my intention to resurrect (and repair) that code at some point, though Marcus never responded to my query about what it was helping and how it broke. I have a guess as to the latter, but I'd have to reinvent an understanding of the feature from scratch in order to write a suitable test for it (none ever existed before). Meanwhile, the "disabled" directory keeps it more on the radar. :-)

[fhgwright]

@mascguy

I'd originally thought about using a separate directory, but using a separate branch seems cleaner. It's also easier to use, since merging the branch with the master branch puts the tests in the expected place, with no Makefile changes needed.

I misspoke a bit here, since the new branch already includes the master content, but merging with a future version of the master branch would do the above.

Is it possible that the "locked-down" aspect you're referring to is just the block on merge commits, which AFAIK applies to macports-ports but not macports-legacy-support? I believe that exists because with the huge number of contributors and large number of committers to macports-ports, there's a significant risk of accidentally making an unintended merge commit, even with the PR merge policy set to "rebase and merge". That's certainly not an issue here, where almost all PR "merges" are effectively fast-forward "merges", though not literally, since the PR merge process rewrites the commit dates and committers, and hence changes the commit IDs.

In general, there seems to be an all-or-nothing attitude toward merge commits, with some projects using them for every PR merge, and others treating them as abject evil. AFAIK, no SCM other than git has the merge-commit concept at all, so that people coming to git from other SCMs are unfamiliar with them, and hence resistant to them. IMO, it's best to understand the pros and cons of merges vs. rebases, and use each where it's most appropriate (though admittedly it's not always cut-and-dried). The short-form difference is that merges have a history which is honest but not linear, while rebases have a history which is linear but not honest (though fast-forwards are both).

I don't expect this branch to get updated very often, though I believe that that can be done via PRs once it exists, as long as it's specified as the target branch in the PR.