<div dir="auto"><div>I wasn't suggesting it for any of the purposes you talked about here. I was suggesting it because it's easier to see changes via the GitHub UI than in a patch in an email. You can make it clear in the commit that that's the *only* purpose of the branch.<div dir="auto"><br></div><div dir="auto">Maybe I'm alone in finding the diff easier to see that way, but I suspect I'm not.<br><div dir="auto"><br></div><div dir="auto">Jon</div></div><br><br><div class="gmail_quote"><div dir="ltr">On Sat, 15 Sep 2018, 17:40 Paul Eggert, <<a href="mailto:eggert@cs.ucla.edu">eggert@cs.ucla.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Jon Skeet wrote:<br>
> Have you considered adding this to GitHub, but in a separate branch?<br>
<br>
I considered it, but in the past I've avoided publishing multiple branches due <br>
to the complexity and confusion that they inevitably entail. Although larger <br>
projects need multiple branches, tzdb is a small one, and I would rather not <br>
maintain separate branches for each alternative-universe prediction of what will <br>
happen in Europe next year. We can install something along the lines of the <br>
patch at an appropriate point assuming the proposal becomes official and after <br>
further info rolls in. As the patch should affect only future timestamps, it <br>
shouldn't break too many people's cell phones when it's installed, and there is <br>
an advantage to sticking to a single prediction even if the prediction is wrong <br>
on some details.<br>
<br>
The main point of publishing the patch now was not to predict what Finland or <br>
the UK would do: it was to point out technical details that need to be ironed <br>
out no matter what they do. The main problem, as I see it, is time zone <br>
abbreviations; a secondary problem is whether summer 2019 will be considered <br>
daylight saving time or standard time in Europe.<br>
</blockquote></div></div></div>