Re: [PATCH] logging branch deletion to help recovering from mistakes
- From
Jeff King <peff@peff.net>
- Date
- Dec 7, 2010, 18:20 UTC
- Message-ID
- <20101207182040.GA26770@sigill.intra.peff.net>
- In-Reply-To
- <AANLkTimnp3xCHp_3E7ry-5OQL3PFnYh=H8PhfzMN307C@mail.gmail.com>
On Tue, Dec 07, 2010 at 10:14:19AM -0800, Shawn O. Pearce wrote:
Show 7 quoted lines
> Per check-ref-format, ref names cannot contain two dots. We could > archive ref logs by renaming them, $GIT_DIR/logs/refs/heads/foo > becomes $GIT_DIR/logs/refs/heads/foo..deleted-1. If foo is created > and deleted again, it becomes foo..deleted-2. > > This still causes problems for git reflog show / git log -g because > they want a current ref to enumerate the log of.
That seems reasonable to me. The "reflog show" limitation is just a matter of a simple code fix, though, isn't it? Is there a good reason for this restriction to exist? And even if there is, it would be simple to special case it for ..deleted-* branches.
Show 5 quoted lines
> A different approach might be to have $GIT_DIR/logs/refs/REF_ATTIC, > and special case that in git reflog show / git log -g. When a > ref is deleted, append its entire log onto REF_ATTIC, between two > specially formatted marker lines. When recovering a branch, copy > out the region from the REF_ATTIC log.
That seems a lot less efficient, as we have to linearly search all of REF_ATTIC to get:
1. the reflog for one deleted branch
2. the list of deleted branches
Neither of those is probably particularly performance critical, but it just seems like keeping the logs in files indexed by the original ref names is a more natural fit.
-Peff