On Sat, Jun 1, 2013 at 11:26 PM, Ramkumar Ramachandra <artagnon@xxxxxxxxx> 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 Yes. Not just because that's what "$dayjob" does, but also because that's what gitolite does. > 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 I suspect that's a big reason for why gitolite is so popular, at least with central workflows. It's trivial to set it up so master is ff-only and any other branch is rewindable etc. > 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. Again, for "central workflow" folks, gitolite's log files actually have enough info for all this and more. Coupled with "core.logAllRefUpdates", it's possible to recover anything that has not been gc-ed, even deleted branches and tags. But it would be nicer if git's own reflog is able to do that. Hence my original thought about preserving reflogs for deleted refs (even if it is in a "graveyard" log to resolve the D/F conflict that Michael and Peff were discussing up at the top of the thread). > 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 Hah! Lovely... -- Sitaram -- 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