Re: can we prevent reflog deletion when branch is deleted?

From: Sitaram Chamarty <sitaramc@gmail.com>
Date: Nov 14, 2013, 00:18 UTC
Message-ID: <528416EA.1070307@gmail.com>
In-Reply-To: <CALkWK0=SqCh-82F4ud+AxuzzEezyMWqMvc6HAPoxOk32vUND7A@mail.gmail.com>

[top posting, and not preserving cc's because the original email thread below is just for context; I don't want to force people into a discussion that they may have considered closed :-)]

Is there *any* way we can preserve a reflog for a deleted branch, perhaps under logs/refs/deleted/<timestamp>/full/ref/name ?

Whatever it was that happened to a hundred or more repos on the Jenkins project seems to be stirring up this debate in some circles.

Just some basic protection -- don't delete the reflog, and instead, rename it to something that preserves the name but in a different namespace.

sitaram

On 06/01/2013 11:26 PM, Ramkumar Ramachandra wrote:

Show 41 quoted lines

> Sitaram Chamarty wrote:
>> I think I'd have to be playing with *several* branches simultaneously
>> before I got to the point of forgetting the branch name!
> 
> Yeah, I work on lots of small unrelated things: the patch-series I
> send in are usually the result of few hours of work (upto a few days).
>  I keep the branch around until I've rewritten it for enough re-rolls
> and am sufficiently sure that it'll hit master.
> 
>> More to the point, your use case may be relevant for a non-bare repo
>> where "work" is being done, but for a bare repo on a server, I think
>> the branch name *does* have significance, because it's what people are
>> collaborating on.
>>
>> (Imagine someone accidentally nukes a branch, and then someone else
>> tries to "git pull" and finds it gone.  Any recovery at that point
>> must necessarily use the branch name).
> 
> Ah, you're mostly talking about central workflows.  I'm on the other
> end of the spectrum: I want triangular workflows (and git.git is
> slowly getting there).  However, I might have a (vague) thought on
> server-side safety in general: I think the harsh dichotomy in ff-only
> versus non-ff branches is very inelegant.  Imposing ff-only feels like
> a hammer solution, because what happens in practice is different: the
> `master` does not need to be rewritten most of the time, but I think
> it's useful to allow some "safe" rewrites to undo the mistake of
> checking in an private key or something [*1*].  By safety, I mean that
> git should give the user easy access to recent dangling objects by
> annotating it with enough information: sort of like a general-purpose
> "pretty" reflog that is gc-safe (configurable trunc_length?).  It's a
> serves more usecases than just the branch-removal problem.
> 
> Ofcourse, the standard disclaimer applies: there's a high likelihood
> that I'm saying nonsense, because I've never worked in a central
> environment.
> 
> [Footnotes]
> 
> *1* It turns out that this is not uncommon:
> https://github.com/search?q=path%3A.ssh%2Fid_rsa&type=Code&ref=searchresults
>