On 09/12/2012 09:48 PM, Junio C Hamano wrote: > Chris Packham <judge.packham@xxxxxxxxx> writes: > >> Our default MUA has an annoying habit of using a non RFC822 date format when >> saving an email as plaintext. This means the first 12 days of every month we >> run into the ambiguous date problem (our date convention is dd/mm/yy). >> >> I see code in date.c for refusing a date in the future which would have caught >> this... > > The most sane thing to do when you know that your MUA *consistently* > does dd/mm/yy (even though it may annoy you) is to massage its > output before feeding it to Git. And it should be a very simple > matter of a one-liner filter, no? Consistent as long as you save as the default .txt. Some people have trained themselves to use the save as .eml option which uses RFC822 style output. sed 's|Date: (\d+)/(\d+)/(\d+)|\1.\2.\3|' should correct the former and ignore the latter. Could this be done in a applypatch-msg hook? > > Regardless of the correctness of that "we reject timestamps way into > the future" logic, it should be taken as the last resort. If you > are on September 1st, both 9/12 and 12/9 will look like into the > future for more than ten days (which is the cut-off, I think). If > you are on December 28th, both look like sufficiently in the past. > Duly noted. And I'm implying that the reject timestamps in future isn't actually working. I've just started looking at t0006-date.sh so see if I can prove it. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html