El 24/04/2010, a las 11:40, Jakub Narebski escribió:

quoted text
> 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 from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html