[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: > 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 > -- 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