Re: Question about 'branch -d' safety

From: Jakub Narebski <jnareb@gmail.com>
Date: Jul 11, 2010, 19:05 UTC
Message-ID: <201007112105.40951.jnareb@gmail.com>
In-Reply-To: <7v1vb9hnd9.fsf@alter.siamese.dyndns.org>

Dnia niedziela 11. lipca 2010 20:41, Junio C Hamano napisał:

Show 18 quoted lines

> Clemens Buchacher <drizzd@aon.at> writes:
> 
> > Known issues:
> >
> >  - The reflog cannot be accessed while the ref does not exist.
> >
> >  - Older git versions will not resurrect the reflog, and therefore
> >    leave the renamed reflog behind.
> >
> >  - Breaks t7701, because git-expire tries to lock log entries,
> >    which fails because ~ is an illegal character for refs.
> >
> >  - Breaks t9300.
> 
> Perhaps a few obvious ones are missing?
> 
>  - It is no longer possible to get rid of objects associated with the
>    history of a branch by deleting the branch and then running gc.

I think that reflog for deleted branches would still follow gc.reflogExpire and gr.reflogExpireUnreachable, and that it would be automatically deleted when it becomes empty. I don't know if provided implementation assures this.

>  - It is no longer possible to trust git that you would start a history of
>    a branch afresh when you create one.  If you happened to have an
>    unrelated branch with the same name in the past, the new branch
>    inherits reflog entries when it shouldn't.

That's a valid concern.

> 
> What problem are you guys really trying to solve?

The problem is that if you delete branch by accident, it might be hard to restore it, and its reflog vanishes forever. And with relaxed protection of 'git branch -d' this might happen more frequently (in the case of circular origin's).

-- 
Jakub Narebski
Poland