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,
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
My original question was: are these the best definitions of those
shortcuts? I have not seen any answer to that.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html