On Tue, Sep 24, 2013 at 12:37 AM, Jeff King <p...@peff.net> wrote: > On Tue, Sep 24, 2013 at 12:32:46AM -0500, Felipe Contreras wrote: > >> > You are making things more consistent for people who already define >> > those aliases in the same way (they are available everywhere, even if >> > they have not moved their config to a new installation), but less so for >> > people who define them differently. Rather than get an obvious: >> > >> > git: 'co' is not a git command. See 'git --help'. >> > >> > the result will be subtly different (especially so in the case of >> > "commit" versus "commit -a"). >> >> Before: >> >> # machine A: git ci >> git: 'ca' is not a git command. See 'git --help'. >> >> # machine B: git ci >> commits >> >> After: >> >> # machine A: git ci >> no changes added to commit (use "git add" and/or "git commit -a") >> >> # machine B: git ci >> commits > > That is the output if there are no files to commit. What about while > resolving a merge, or after using "git add" on a path? In that case we > create a commit, but it is subtly different than what the user intended.
It might be different, but it might not. 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. -- Felipe Contreras -- 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
