On Tue, Sep 24, 2013 at 12:49:21AM -0500, Felipe Contreras wrote: > Anyway, if you are so worried about this hypothetical user not > noticing that 'git ci' didn't commit all the files, we could ma ci to > 'git commit -v' so we are being straightforward to the user as to what > is being committed. I do not think that is a useful suggestion, as the output of "commit -v" is typically too long for unsuspecting people to check carefully, and is redundant with the filename summary we already put in the commit template. And neither is shown with "-m", anyway. I agree it's a minority of cases where somebody will make a bogus commit because of it, though. But let's take a step back for a moment. What was the goal of the patch? Who are we trying to help? People who already have identical aliases are not helped on existing boxes; they already have them. They might be helped on new boxes, where they will not have to copy over their custom aliases (but they would probably end up wanting to copy the rest of their config and aliases anyway). People who have different aliases for the same terms are unaffected on existing boxes, but slightly hindered on new boxes as the aliases do something else. People with no matching aliases now get these aliases. What do they expect them to do? Do they expect "commit" or "commit -a"? Do they expect "status" or "status -s" or "status -sb"? Are we trying for consistency across git installations, or consistency with similar aliases in systems like cvs (in which case, would that argue for "commit -a")? Do people who have not bothered to configure the aliases even care? My original question was: are these the best definitions of those shortcuts? I have not seen any answer to that. -Peff -- 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