CODEWITHSUNDEEP
gitshelldateversion-control
Maxim Korobov
Maxim Korobov

Reputation: 2572

Get commit history after date (since/after parameter)

It`s 8 of March now. I want to see git history since 1 of March. For that I'm using command:

$ git log --pretty="%cd - %h - %an - %s" --after="2013-3-01 0am"

It works fine. Then I want to see history "in future" (since 8 of March increase after value by +1 day). Example:

$ git log --pretty="%cd - %h - %an - %s" --after="2013-3-11 0am"

Command returns empty history, which is correct. Then after value equals to 18:

$ git log --pretty="%cd - %h - %an - %s" --after="2013-3-18 0am"

Git starts to return full month history. Why? Seems like something wrong with git log date time format in my example.

git version 1.7.12.4 (Apple Git-37)

Upvotes: 1

Views: 195

Answers (1)

cjc343
cjc343

Reputation: 3765

There is an open bug on this issue. If you've built git from source, a test-date utility is included. Here are some results of running various dates through it (note - 18th is no longer the break point for me, so using the 19th):

$ ./test-date approxidate "2013-3-01 0am"
2013-3-01 0am -> 2013-03-01 19:22:21 +0000

$ ./test-date approxidate "2013-3-11 0am"
2013-3-11 0am -> 2013-03-11 19:22:21 +0000

$ ./test-date approxidate "2013-3-19 0am"
2013-3-19 0am -> 2013-03-03 19:22:21 +0000

It's clear the time is problematic in all cases, so lets fix the time:

$ ./test-date approxidate "2013-3-01 0:00"
2013-3-01 0:00 -> 2013-03-01 08:00:00 +0000
$ ./test-date approxidate "2013-3-19 0:00"
2013-3-19 0:00 -> 2013-03-19 07:00:00 +0000

That looks a little better, and our future date is no longer seriously incorrect, but the times are relative to my timezone, and differ between being with and without DST (E: for any future readers, the DST shift occurred 2013-03-10, so those dates do encompass the shift).

$ ./test-date approxidate "2013-3-19 0:00 +0000"
2013-3-19 0:00 +0000 -> 2013-03-19 00:00:00 +0000

Now our date is looking a little better. If I do want the timezone to take affect, it's now easy to change to a -0800/-0700, PST, PDT, or any other timezone.

In short, there are two issues:

  1. Your time is not being parsed properly. Once a time component is included, git gets smarter about parsing dates.

  2. In a quest to parse any date, git discards your dd and uses your mm for a day of the current month:

    $ ./test-date approxidate "2013-3-20"
2013-3-20 -> 2013-03-03 19:22:21 +0000
$ ./test-date approxidate "2013-4-19"
2013-4-19 -> 2013-03-04 19:22:21 +0000
$ ./test-date approxidate "2013-4-32"
2013-4-32 -> 2013-03-04 19:22:21 +0000

Your issue should be fixable by fixing the time and optionally adding a time zone depending on intent.

Upvotes: 1

Related Questions