Re: [PATCH] logging branch deletion to help recovering from mistakes

On Tue, Dec 7, 2010 at 10:25 PM, Michael J Gruber
[off-list ref] wrote:

Nguyen Thai Ngoc Duy venit, vidit, dixit 07.12.2010 12:37:

quoted

On Tue, Dec 7, 2010 at 1:28 PM, Junio C Hamano [off-list ref] wrote:

quoted

Nguyen Thai Ngoc Duy [off-list ref] writes:

quoted

On Tue, Dec 7, 2010 at 4:16 AM, Junio C Hamano [off-list ref] wrote:

quoted

+#define BRANCH_DELETION_LOG "DELETED-REFS"
+

Should this special log be mentioned in git-update-ref.txt or
gitrepository-layout.txt?

Perhaps, but I wasn't sure if this patch itself is a good idea to begin
with.  Not the problem it tries to solve, but its approach.

For example, this cannot be shown with "reflog show" or "log -g" due to
the way these frontends locate the reflog file to read (the logic wants to
have an underlying ref).

I think you have thought of this. What's wrong with keeping reflog
when a branch is removed and appending "delete" line to the said
reflog? I don't know how reflogs are managed, but those reflogs
without associated branch will (or should) be cleaned when they are
expired.

The problem is the following:

Say, you delete a branch and its reflog is kept (with a "delete" line
appended).

Then you create a new branch under the same name. What is supposed to
happen to the reflog? If you simply append, then old (unrelated) entries
will not expire through the imagined "expire branch reflogs" mechanism.

Now, you rename that branch. We should really split the reflog in two
now, keeping the old name for the old parts and moving only the newer
parts to the reflog with the new name.

I don't see any problems with that. If I happen to create a branch
with the same name, most of the time, there is something related,
unless for very generic names like "tmp". We can always notify users
about the accident resurrection of an old branch at branch creation,
so they can remove the old reflog if they want.
-- 
Duy