Hi,
On Mon, 2 Jun 2008, Shawn O. Pearce wrote:
> 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).
That's obvious.
> 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.
I actually would prefer to have the logs in the .git/logs/ directory, so
that I can easily reuse all existing reflog handling.
After sending the mail, I actually got an idea:
.git/logs/attic/<timestamp>/<refname>
I think this should work without problems. In that case, git-gc also
handles the garbage collection.
> 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.
Yes, they should. That is the whole purpose of keeping the reflogs: I
want to be able to resurrect the branch, if I deleted it by accident.
> - What command gets the extra options to see what branches are in the
> attic and when they got there?
I'd like to have them listed with the other reflogs.
> - What command gets the extra option to recover a branch from the attic?
None. It is the user's responsibility to use the information wisely.
git branch resurrected attic/<bla>/refs/heads/accidentally-deleted@{1}
> - 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?
See above. I think resurrecting under the same name would not necessarily
be the most frequent operation on deleted refs.
> - 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).
I'll just go with my idea, implement it, and post it here for discussion.
Ciao,
Dscho
--
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
