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