El 24/04/2010, a las 11:40, Jakub Narebski escribió: > It's a pity that people didn't concentrate on this part: improving > error message... > > > On a bit unrelated note what I'd like to have is 'git commit -a' > (optional) safety against accidentally getting rid of staged changes. > > I'd like for 'git commit -a' to *fail* if there are staged changes for > tracked files, excluding added, removed and renamed files. If you > have some staged changes you would get an error message: > > $ git add tracked-file > $ git commit -a > fatal: There are staged changes to tracked files > hint: To commit staged changes, use 'git commit' > hint: To commit all changes, use 'git commit -f -a' > > Perhaps this behavior would be turned on only if some config option, > like commit.preserveIndex or something like that is set to true...
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. Where do we stop here with the hand-holding? Would you also want a fatal error here?: $ git add foo $ git commit -- bar fatal: There are staged changes to tracked files 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. Cheers, Wincent -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
