When the last backup was a tagged backup and there are no changes, running gsb backup --tag "message" will create a new tag pointing to the same commit as the last tag. Meaning that subsequent calls of gsb history will only show the new tag.
Environment and Version
gsb version: gsb, version 0.0.2
git version: git version 2.42.0
Python version: Python 3.11.5
Operating System:
Arch Linux x86_64 (Kernel: 6.5.3-arch1-1)
Steps to Reproduce
Create a tagged backup
gsb backup --tag "Hi mom"
Without making any changes, create a new tagged backup
gsb backup --tag "Hi dad"
Run gsb history -v
The output will only show the "Hi dad" backup with the actual tagname corresponding to the date of that backup, but the timestamp of the backup corresponding to when the "Hi mom" backup was created, e.g.
gsb2023.09.30+143149 from 2023-09-27-18:36:02
Full reference: 6bbd373d77da885b1e58e053e5f86f9c2299c47f
Hi dad
Workaround
So technically this is an issue in gsb history where it performs the commit -> tag lookup:
No commits or tags have been deleted. Thus, I was able to clean up this mess by running:
git tag -d gsb2023.09.30+143149
after which gsb history -vvn1 correctly showed:
gsb2023.09.27+183606 from 2023-09-27-18:36:02
Full reference: 6bbd373d77da885b1e58e053e5f86f9c2299c47f
Hi mom
Severity
Annoying
Desired Outcome
Fix: desired behavior is that if there are no new changes and the last backup was "tagged" then the backup should cancel with a "no new changes" message.
There may be a use-case for a gsb backup --edit-annotation method, but that's out-of-scope
Urgency
By next major release (though I'm provisionally assigning this to the scope for v0.0.3)
Summary
When the last backup was a tagged backup and there are no changes, running
gsb backup --tag "message"will create a new tag pointing to the same commit as the last tag. Meaning that subsequent calls ofgsb historywill only show the new tag.Environment and Version
gsb, version 0.0.2git version 2.42.0Python 3.11.5Steps to Reproduce
gsb history -vThe output will only show the "Hi dad" backup with the actual tagname corresponding to the date of that backup, but the timestamp of the backup corresponding to when the "Hi mom" backup was created, e.g.
Workaround
So technically this is an issue in
gsb historywhere it performs the commit -> tag lookup:https://github.com/OpenBagTwo/gsb/blob/4847bae3d9db3b9643a1994ca803036165fdb020/gsb/history.py#L68-L70
No commits or tags have been deleted. Thus, I was able to clean up this mess by running:
after which
gsb history -vvn1correctly showed:Severity
Annoying
Desired Outcome
Fix: desired behavior is that if there are no new changes and the last backup was "tagged" then the backup should cancel with a "no new changes" message.
There may be a use-case for a
gsb backup --edit-annotationmethod, but that's out-of-scopeUrgency
By next major release (though I'm provisionally assigning this to the scope for v0.0.3)
Notes