Sverre Rabbelier <srabbelier@xxxxxxxxx> writes: > On Fri, Dec 18, 2009 at 13:49, Junio C Hamano <gitster@xxxxxxxxx> wrote: >> You might type >> "commit" when you meant to say "commit -a" and record an incomplete state; >> it is "dangerous" in that sense. > > Speaking of which, it has hit me multiple times that I craft out a > commit with 'git add -p' and then do "git commit -am 'foo some bars'" > and lose all my hard work (because I'm used to typing 'git commit -am' > for temporary commits). I'd be happy if "git commit -am" learned to > second-guess me when I already have something in the index. Sounds like "commit.confirm = xxx" configuration patches are coming? What other questionable operations we might want to let users configure git to ask for confirmation? > Fair enough, then perhaps it is time for "core.nodataloss" which > either logs states to a seperate reflog (so that you can go back to > the state you were in before doing 'git read-tree') or interactively > informs the user that this will command will result in data loss > (although that sounds a tad too much like Window's "Are you sure?" > dialogs). I somehow suspect that you had your morning coffee yet ;-) Aren't we talking about the index, and why are you bringing up the reflog? More importantly, if you accept that there are non-interrogator commands in the git command set, I somehow suspect that you will soon realize that "git config core.nodataloss true" is equivalent to "chmod a-w -R .". It might be useful mode of non-operation (read-only historical archive) but I do not think it deserves a configuration of its own with checks in the code all over the place that might possibly change any states of the repository. "git config user.novice true" to increase the verbosity and degree of hand-holding is an entirely different matter, but if that is what you are advocating, you shouldn't call it "core.nodataloss". -- 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