[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
On 06/01/2013 11:26 PM, Ramkumar Ramachandra wrote:
> 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
> *1* It turns out that this is not uncommon:
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html