Johannes Schindelin <Johannes.Schindelin@xxxxxx> wrote: > _However_, I still try to come up with some attic for deleted refs. It is > not just a matter of moving the logs to a different namespace because of > D/F conflicts. Record the delete at the end of the reflog so we have a date/time record and the last SHA-1 value, just in case it doesn't match up with the most recent reflog entry (e.g. user ran some legacy tool that just redirect git-commit-tree output to the branch itself). Take the SHA-1 hash of the reflog now that the final entry is written. Rename the file to .git/attic/$sha1 and call it a day. I thought about compressing the file too, but its not worth saving the disk space here and it would make tools that inspect the attic expensive to run. The attic can be easily cleaned out by looking at the timestamp of the last record of each file. Attic log files older than X days can be removed. This is better than reading the modification time of the file as we don't have to worry about some copy tool not saving the modification time if the user moves/copies the repository. That's all the easy stuff. The hard stuff is: - Should the commits listed in attic reflogs be considered reachable when we pack, prune or fsck? Commits in a reflog are, even if they aren't reachable from a transport perspective. - What command gets the extra options to see what branches are in the attic and when they got there? - What command gets the extra option to recover a branch from the attic? - When we recover a branch from the attic is it sufficient to recover it to the name it had at time of deletion? Should we allow you to recover it to a different name? - Is it sufficient to make you recover the branch from the attic before you can access the rest of its reflog with porcelain? - What do we do if we recover a branch with stale reflog entries and the attic is deemed to not be reachable (see above). -- Shawn. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
