Adds the method history.get_history, which meets the specs of #4 by:
Allowing the user to either fetch all annotated tags or all commits
Optionally limiting to only the last n revisions
Optionally limiting to only revisions on or after a specified timestamp
Optionally including commits and (annotated) tags created manually, outside of gsb
All returned in reverse-chronological order
Modifies _git.log to return a generator that fetches the commits one at a time
Adds a .pylintrc (that I forgot to include in 4cb7fc9b01b97ccb825e1dae8824e6dca47b6bcb)
Tech Debt and Other Concerns
Timestamp resolution means tests need to sleep
It appears that Git itself only resolves timestamps to the second, which means that I'm having to put in a sleep to test the operation of the since kwarg.
This is mitigated in 9f7242cabfba348d062ef128952bb208a3c28c6f via use of pytest's tmp_path_factory fixture to make it so that the git repo needs to be created only once. This is a pattern that should be used sparingly but is safe in this case because gsb history does not make any changes.
Explicitly note that this does not affect the ordering of commits--that is guaranteed by the linear history and the fact that we're walking through the commits one at a time
author time or commit time?
Looking over the git history, I was surprised it didn't go back farther. Then I remembered that I'd done a bunch of rebasing and realized it was probably using the date of the rebase.
In actuality, I just misread the timestamps, but it did clue me into the fact that I have to be very intentional about whether this line:
uses commit.commit_time (the time of the squash or cherry-pick) vs. commit.author.time, which is the time the original commit was made.
What I want is to use the time the last commit was made, but I don't think that's recoverable, so it just needs to be noted in #9 that squashing needs to preserve the last date.
Validation Performed
[x] Unit tests :-)
Tried running this on my own manually-git-managed Minecraft saves folder (which use squashed commits instead of tags), and:
[x] history.show_history(my_saves) returned empty (because it's not using gsb yet)
[x] history.show_history(my_saves, include_non_gsb=True) returned empty because I've got no tags
[x] history.show_history(my_saves, include_non_gsb=True, tagged_only=False) got me metadata on all commits going back to the start of that repo
[x] history.show_history(my_saves, include_non_gsb=True, tagged_only=False, limit=10) got me metadata on the last ten commits
[x] I have run mkdocs serve locally and ensured that all API docs and
changes I have made to the static pages are rendering correctly, with all links
working
[x] All tech debt concerns have been resolved, documented as issues, or otherwise
accepted
Summary
Addresses #4, save for the CLI
List of Changes
history.get_history
, which meets the specs of #4 by:n
revisionsgsb
_git.log
to return a generator that fetches the commits one at a time.pylintrc
(that I forgot to include in 4cb7fc9b01b97ccb825e1dae8824e6dca47b6bcb)Tech Debt and Other Concerns
Timestamp resolution means tests need to
sleep
It appears that Git itself only resolves timestamps to the second, which means that I'm having to put in a
sleep
to test the operation of thesince
kwarg.This is mitigated in 9f7242cabfba348d062ef128952bb208a3c28c6f via use of pytest's
tmp_path_factory
fixture to make it so that the git repo needs to be created only once. This is a pattern that should be used sparingly but is safe in this case becausegsb history
does not make any changes.Explicitly note that this does not affect the ordering of commits--that is guaranteed by the linear history and the fact that we're walking through the commits one at a time
author time or commit time?
Looking over the git history, I was surprised it didn't go back farther. Then I remembered that I'd done a bunch of rebasing and realized it was probably using the date of the rebase.
In actuality, I just misread the timestamps, but it did clue me into the fact that I have to be very intentional about whether this line:
https://github.com/OpenBagTwo/gsb/blob/d5874a072329e010a91987b62ab5095486465e28/gsb/_git.py#L257
uses
commit.commit_time
(the time of the squash or cherry-pick) vs.commit.author.time
, which is the time the original commit was made.What I want is to use the time the last commit was made, but I don't think that's recoverable, so it just needs to be noted in #9 that squashing needs to preserve the last date.
Validation Performed
history.show_history(my_saves)
returned empty (because it's not usinggsb
yet)history.show_history(my_saves, include_non_gsb=True)
returned empty because I've got no tagshistory.show_history(my_saves, include_non_gsb=True, tagged_only=False)
got me metadata on all commits going back to the start of that repohistory.show_history(my_saves, include_non_gsb=True, tagged_only=False, limit=10)
got me metadata on the last ten commitsPR Type
release
)Checklist:
mkdocs serve
locally and ensured that all API docs and changes I have made to the static pages are rendering correctly, with all links working