Any thoughts on what if anything it should do on encountering file names with embedded whitespace (which on unix can even include newlines)?

In the context of vpatches I don't see a good solution, but for the sake of honestly I considered aborting vdiff process or at least reporting that the vpatch is borked to stderr, as most likely no V presser/patcher would be able to do anything with it.

Although that was for a genesis, where the diff hunks are fully determined anyway.

I'd say it makes a good example of the importance of choosing optionality wisely, because putting it in one place closes it off in another.

> it does have some crap that should go.

Ah yes, the "quoting is good mmkay, so let's do it, sometimes, if we feel like it".

Any thoughts on what if anything it should do on encountering file names with embedded whitespace (which on unix can even include newlines)?

And, well, the "standard utility" is also implemented in some ~1000 LoC even with busybox. This is not to say that vdiff could not use some improvement: it does have some crap that should go.

I can't say I like the idea of needing a 2k+ line GNUistic vdiff compared to <100 lines of awk on top of a standard utility, or this bitcoin-like situation where "the code is the spec and realistically there can be only one implementation", or the idea that all vdiffs must produce the same output anyway as that closes off improvement of the algorithm. Do you have a ref handy for why identical output is important? I recall complaints about locale-dependent file sort order from the logs but not beyond that. Anyway, thank you for the caution and I will probably do as you suggest, as this doesn't seem like a battle I can or need to win.

IMO if you want to get rid of Ada dependency, it's better to move vdiff to keksum code instead of relying on whatever diff busybox has -- also because if you diff two trees, it's not guaranteed that phf's vdiff and busybox+wrapper will produce identical hunks inside the vpatch.

This wasn't previously a required part of the unified diff format, and at least busybox diff doesn't include it (see also). It also means one might need to be more careful in any commentary at the top of a patch file.

Still, I'm thinking this is the saner way to go since it simplifies any tool that needs to parse patches while complicating only theoretical vdiffs that don't conform; nicely anti-Postel if we can afford it.

If you consider a case of more vpatches, then genesis is not special vpatch in any way (so I guess Is_Genesis is rather misleading name) - it just happens that all other vpatches have this one vpatch - genesis - as their antecedent, while not all vpatches have the vpatch with manifest in their antecedent set.

A vpatch is genesis if all its hunks are file creations.

Hmm, this risks to misfire for instance on older trees that have the manifest added at some point rather than baked in from the start. Arguably they are due for a regrind anyway but the above definition (and its implicit reliance on the manifest file mechanism) sits rather uncomfortably with me. To my mind a vpatch is genesis if it doesn't have any ancestors - would this be all that harder to use at this specific point?