On Mon, 19 Jul 2010, Junio C Hamano wrote: > If you take an analogy in say a file server implementation, yes, it should > not be easy to lose information there. But it is and should be easy to > say "rm junk". How would people recover from a mistake if they typed a > wrong filename, "rm junio" to lose a precious file "junio", when they > meant to lose "junk"? They go to backups. First, I guess that many people have 'rm' aliased to 'rm -i', so it asks for confirmation... though it only moves safety a bit, as 'rm -f junio' would be still dangerous. Second, desktop environment have the notion of trashcan, where files to be deleted are moved, and kept for some time or untill trashcan is emptied (though it moves safety a bit to people using 'hard delete' instead of moving to trashcan). Or use undeletefs, > Can't git users do the same? > After all, .git directory is stored on a filesystem of some sort, and > taking a backup (you do take backups, don't you?) and picking the stuff > you lost from there should be a standard procedure that can be learned > outside of the context of git. People expect version control system to protect them more from mistakes. Sidenote: there aere requests in last Git User's Survey (from 2009) to have safety net against losing changes due to "git reset --hard", in the form of automatically stashing blobs or something. > > This is pretty-much a tangent, but I recall from time to time people > wonder why the branch namespace is not flat. If that is a common wish, > your "tilde-suffix all the intermediate path components" trick could be > used in later versions of git (perhaps 1.8.X series) to improve the system > to allow "maint-1.7.0" branch and topic branches that forked from it > e.g. "maint-1.7.0/fix-frotz" and "maint-1.7.0/fix-nitfol" peacefully > co-exist. Hmmmmm... true, this would make having 'foo' and 'foo/bar' branches coexists, whether they are loose or packed, and whether they have reflogs or not. -- Jakub Narebski Poland -- 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