Issue #253: almost duplicate records in commit history
| Reported by: | Karl Goetz |
| State: | resolved |
| Created on: | 2016-11-12 01:19 |
| Updated on: | 2016-11-18 11:37 |
Description
(title is poor, feel free to change it).
I took the following steps: - dropped a non bare git repository in my kalithea/repositories directory - ran the scan and update tool to populate kallithea - noticed i had committed as root, so ran an update over all records to set myself as committer - ran the scan and update tool to populate kallithea
The repository now contains both sets of commits.
Revision Commit Message Age Author Refs 082e5153efc5 Floating heading works at last 2 hours and 4 minutes ago kgoetz master cf0aee0873e3 Floating heading works at last 2 hours and 4 minutes ago root 968fef58c3ef Moved to 'stacked pills' for the human sitemap 2 days and 15 hours ago kgoetz e27581f0f2c4 Moved to 'stacked pills' for the human sitemap 2 days and 15 hours ago root
I'm unsure what the appropriate fix is here (other than 'dont do that') since the revision has changed and I assume that is what kallithea is tracking. Is it possible to fix? if not I'll add it to my notes and move on.
thanks!
Attachments
Comments
Comment by Mads Kiilerich, on 2016-11-13 13:29
That sounds like a git usage issue, not related to Kallithea.
Comment by Karl Goetz, on 2016-11-17 04:15
is there a way to request kallithea forget the contents of the repository so it can import them anew?
Comment by Mads Kiilerich, on 2016-11-18 00:03
Kallithea doesn't remember any repo hisotry. It just shows what is in the git repository.
Comment by Karl Goetz, on 2016-11-18 11:37
I'm not sure what or when, but this is working as expected now. Its possible the records were due to being a non bare repository, due to kallithea needing a restart (?), rescan failing, ... I don't know. Whatever the case during the last week this repository is now behaving itself.