Nguyen Thai Ngoc Duy venit, vidit, dixit 07.12.2010 12:37: > On Tue, Dec 7, 2010 at 1:28 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: >> Nguyen Thai Ngoc Duy <pclouds@xxxxxxxxx> writes: >> >>> On Tue, Dec 7, 2010 at 4:16 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: >>>> +#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. This is all workable in principle but hints at a design flaw. Maybe it's easier to teach "git reflog" about "DELETED_REFS"? Michael -- 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