feat(record): add --allow-empty flag#1612
Draft
claytonrcarter wants to merge 4 commits into
Draft
Conversation
83f931b to
a897fc4
Compare
ca86bfb to
6a2e4b6
Compare
6a2e4b6 to
3e69d17
Compare
3e69d17 to
a09e084
Compare
a09e084 to
fc40d4c
Compare
This was referenced May 19, 2026
515dd24 to
6dee839
Compare
DUMMY_DATE is used to populate GIT_AUTHOR_DATE and GIT_COMMITTER_DATE, both of which expect dates in RFC2822 format, but DUMMY_DATE was itselt not in RFC2822 format, and it was made less so by appending a 2 digit timezone offset. This has not been an issue thus far because we were only passing the date to git as a string, and git seems to be fairly liberal when parsing dates. `git record --new` seems to be the first time we're actually creating wholey new commits (vs just modifying existing commits), so we need to set a current time on these new commits. To do so, we need to parse DUMMY_DATE into a SystemTime with chrono, and chrono is not lenient when parsing dates, leading to various errors: 1. The existing format yielded Invalid, because of the time/year order. 2. Fixing the order of the year led to TooShort, because of the 2 digit timezone offset. 3. Fixing the timezone offset yielded Impossible, because 2020-10-29 was not a Wednesday. Fun! Regardless, I don't expect these changes to have any impact outside of the upcoming tests for `record --new`. Old format: Wed 29 Oct 12:34:56 2020 PDT -02 New format: Thu, 29 Oct 2020 12:34:56 -0200 Ref: https://github.com/git/git/blob/master/Documentation/date-formats.adoc Ref: https://www.rfc-editor.org/rfc/rfc2822#section-3.3
`record --new` is the first feature in which we create entirely new commits (vs rewriting or splitting existing commits) and I was running into test failures in CI that seemed to only differ by timezone. Explicitly setting the time zone in the test git environment resolved the issue.
Fixes various defects encountered during testing.
6dee839 to
858e15c
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This adds
--allow-emptysupport togit record. This is not very interesting on it's own, but the fun starts when you pass--insert, at which point this should behave as a short hand forgit commit --allow-empty -m ... ; git move -s 'siblings(@)'.As is, this change will only create an empty commit if there are no changes at all (staged or in the working copy). Eventually, it would be nice to have "real" support for
record --newto create an empty commit regardless of what changes are currently staged or in the working copy, but I don't intend to tackle that at this time.