commit 39688b2454965eb45aa2f02a3f078adeee06ccd1
author philwo <philwo@google.com> Wed Nov 28 02:19:46 2018 -0800
committer Copybara-Service <copybara-piper@google.com> Wed Nov 28 02:21:21 2018 -0800
tree 5fdd62b419de1806aca1856ae13952543bf3c296
parent 4c3d260a6742a4de3fc6bfb4340bd460aec28e49

git.bzl: Use the "raw" format when generating the shallow_since date.

Git's "raw" date format is defined as: "seconds since epoch" "timezone"
Example: 1541794679 +0100

It's unambiguous and easy to parse for Git. This solves an issue where commits would not be found when they were made on the same date as when Bazel tried to 'git clone' a repository from a WORKSPACE.resolved file. This was also the reason why test_resolved_file_not_remembered was flaky.

Thanks to aehlig@ for extracting the flaky test into an easy to run repro example shell script!

Background story:

Previously, we were using the '%Y-%m-%d' format, but when Git parses this, it will not assume '00:00:00' (midnight) as the corresponding time of that timestamp, but will use the *current* local time! SURPRISE! That causes problems when the commit happened earlier on the same day as when you were trying to use it in a git clone: Git will see the following:

# I'm working on my awesome external repo.
$ git commit -m'Finally done with this'
# The commit has the date: 2018-11-27 22:56:03 +0100

# Now I'm trying to use this in Bazel via a resolved repository file.
# Bazel will then generate a "shallow_since" attribute from the commit
# date in order to save bandwidth and will use that for the next Git clone.
# However, because now it's one minute later...
$ git clone --shallow_since=2018-11-27 https://github.com/philwo/awesome-repo
# Git expands the timestamp to "2018-11-27 22:57:03" and not "2018-11-27 00:00:00"! Thus:

fatal: no commits selected for shallow requests
fatal: the remote end hung up unexpectedly

What!? Where's my commit? Git, usually you have such a wonderful UX, why do you fail me this time?

After debugging into Git's code with gdb, the fix is obvious: Just generate an unambiguous date format when generating the resolved workspace file, then Git doesn't embed the current time into the date and all works well.

This also fixes the flaky test_resolved_file_not_remembered test.

RELNOTES: None.
PiperOrigin-RevId: 223133745