Dnia sobota 24. kwietnia 2010 18:42, Petr Baudis napisał: > On Sat, Apr 24, 2010 at 01:10:24PM +0200, Wincent Colaiuta wrote: >> El 24/04/2010, a las 11:40, Jakub Narebski escribió: >>> >>> I'd like for 'git commit -a' to *fail* if there are staged changes for >>> tracked files, excluding added, removed and renamed files. > > Thanks for this suggestion, this is exactly what I wanted to propose! > +1 here. > > I think this could even be made a default in some time, I don't see any > useful workflows this could prevent and adding -f is trivial enough for > those who really want to go forward. Isn't it how (most of) backwards incompatibile changes are made, first adding an option for new behaviour, then later (optionally) changing the default? >> For me this is going to far. While we don't want to make it _easy_ >> for users to shoot themselves in the foot, neither do we want to make >> it difficult or impossible for them to get the tool to do things that >> _might_ be a mistake. And what's the risk here? Accidentally >> committing too much is not a destructive change, and can be easily >> undone. > > Have you ever done this mistake? If you have done some extensive index > editing, it is actually a major PITA to restore, and can be even > destructive if your index and working tree are too much out-of-sync > (this does happen to me not so seldom while I also use -a a lot for > trivial commits). That is the situation this *optional* safety is meant to protect against: when somebody sometimes use "git add" + "git commit", but sometimes use "git commit -a", to protect carefully index against accidental "git commit -a" instead of "git commit". Is it worth additional code complication? Shoult it be turned on by default? Does it promote unsafe workflow of committing untested changes? >> IMO, the fact that the commit message editor is populated with >> a list of changed files that will be included in the commit is enough >> for people to see what's actually going to happen. > > BTW, I almost always use -m instead of the commit editor. ;-) So restructuring commit message template so the information is more visible in the case of accidental "git commit -a" wouldn't always help... -- 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