Dnia sobota 24. kwietnia 2010 13:10, Wincent Colaiuta napisał:
El 24/04/2010, a las 11:40, Jakub Narebski escribió:
quoted
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.
What you cant recover by undoing commit is the state of index before
accidental 'git commit -a' instead of 'git commit'.
Where do we stop here with the hand-holding? Would you also want
a fatal error here?:
$ git add foo
$ edit foo # without this safety would not trigger for "git commit -a"
$ git commit bar
fatal: There are staged changes to tracked files
No, I wouldn't. First, there is much less chance of mistake here, IMHO,
and second you don't loose staged changes to 'foo' here.
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.
Note that in original post there was patch restructuring a bit this info,
for relevant information to be more visible.
--
Jakub Narebski
Poland