Date: Mon, 15 Aug 2022 16:21:52 -0700 From: Paul Eggert <eggert@cs.ucla.edu> Message-ID: <47967be4-875f-368b-54a0-580a5d96703d@cs.ucla.edu> | Sure, and 'patch' often goofs up - which is partly my fault as I am one | of the three maintainers for 'patch'. I don't think I have ever seen patch, when given any of the forms of context diff, "goof up" - unless you include not being able to apply the patch (because the context of the source has changed since the patch was created) as such a goof - I don't. It does odd things sometimes in non-context forms, when it is relying on just line numbers to identify where the patch goes. That only works (can only be expected to work) when the base file has not altered at all. | Plus, 'patch' is just part of the job. Often the commit message is just | as important as the actual change. 'git format-patch' and 'git am' | handle this nicely; 'patch' does not. Yes, but it was that which I was referring to here: | > in non-compiled data (data not subject | > to automated checking) I tend to make all kinds of typos, which would | > need correcting, and second, because the kind of comments I would supply | > are unlikely to be the kind you'd be willing to commit. Not to the data that would be being put into the file, which would not be ... | It's OK if typos are limited to 'backzone' as it has unimportant data. that one, as I will only do this if the data goes back in the files from where it has been removed (those are what I work with), and in any case, none of the data is unimportant, whatever file it happens to be placed in. Separating out the data, and just having the mindset that some of it is unimportant, is what leads to problems like the issues that Bradley White identified with 2022b/2022c. But back to the point, it is the commit message that would likely have lots of typos (look at some of my commits to NetBSD - the log messages are full of stuff like that, unfortunately), and most likely also have comments that you are unlikely to want to have stored in the git history of the data. You'd not be saving any work by getting a git format patch from me, probably actually adding steps. | Plus, you can always fix any typos later, whenever you get around to it. | As for comment format let's see what sorts of comments you write: if | others who care about 'backzone' don't care about the comments then I'm | not likely to care either. So, that's not relevant - unless git allows the log entries to be revised, in which case, that's just one more strike against git. Obviously the data in the file (whether that be data that zic processes, or comments) is subject to later revision, that didn't need saying. | > | Europe/Pristina, and this is a win. | > I don't recall seeing anyone request one | Here's one example: | https://mm.icann.org/pipermail/tz/2014-January/020589.html It is no wonder I did not remember that, but neither that short thread, nor the one from May 2013, really amount to a request to add the zone - more a "I wonder if we should be adding ..." type thing. The earlier discussion seemed to be most concerned about whether Kosovo is a country or not, which is irrelevant to me (I'm sure it is important to many people, but I'm not one of them, and it should never be important here either - fine to add an assigned country code if it has one, but even if it doesn't, it still has time). With hindsight, back then would probably have been a good time to at least create the zone name as a link. I certainly don't see any problems doing so would have caused (beyond the normal extra effort creating any new zone requires.) kre