* Dave Mitchell <davem@iabyn.com> [2016-09-20 14:12]: > How about we just don't bother keeping MANIFEST strictly sorted during > development, (and so don't automatically test it for sortedness), and > instead have it as an extra manual step in the release process ("step > 97: run 'make manisort' and commit if MANIFEST has changed"). So it > just gets done once per month and doesn't get in the way of everyone > else. I had the same thought to begin with. Then I thought on it a little further, and ended up disagreeing. If we want MANIFEST to be sorted at all, then we should make sure that additions to it go in the right place within the commit that adds them, and we should avoid commits that reorder the file in bulk, because that is the only way to minimise spurious merge conflicts on that file. Try to rebase a branch to a new release? Here, hand-clean the MANIFEST! But writing that down served as my talk-to-the-teddybear: it reminded me that you can set up custom merge drivers for particular files in Git. We could write one for MANIFEST which diffs against the base on both sides, applies all deletions regardless of original context, de-dupes additions from both sides, appends them all, and sorts the result. The only source of conflicts (which it has to check for) would be if both sides happened to add the same path but with different comments (which never happens in practice but must be caught if it does). But if we’re writing tooling anyway, it would not be hard to also write some to keep the file sorted in the ordinary course of development. That would further keep the noise in commitdiffs to a minimum. Then we should move the test for proper sorting to the release process, so it stops bothering vendors patching in stuff during *their* build. The alternative to all this is to say we don’t care about the order in MANIFEST at all, ever. Not during development, not in release tarballs, never. > That does however leave open the issue of whether we should still > automatically check for correctness (i.e. that MANFEST == git ls-files). That should stay. There should maybe even be a hook for it. * Father Chrysostomos via RT <perlbug-followup@perl.org> [2016-09-21 18:36]: > On Wed Sep 21 07:00:45 2016, demerphq wrote: > > By the way there is an option available that we did not discuss. We > > could simply make the manifest sort contingent on being in a git > > repository with uncommitted changes to MANIFEST. > > > > That would make both of us happy right? > > Would it not still cause the problem that was the subject of this > ticket to begin with? It seems to me that we are using fragile fixes > to fix fragile fixes when we could just ‘not do that’ to begin with. It seems not a fragile fix to me but exactly the right idea. Though it could be a pre-commit hook – any time MANIFEST is dirty, just sort it before committing it. That would not address people who run tests prior to committing, but if the automation takes care of this well enough that we feel free to move the check for sortedness to the release process, they will no longer be nagged in the first place. * Desmond Daignault via RT <perlbug-followup@perl.org> [2016-09-21 01:48]: > Can the MANIFEST file be sorted via a git hook? :-) Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/>Thread Previous | Thread Next