Jeff King venit, vidit, dixit 25.02.2011 10:01: > On Fri, Feb 25, 2011 at 09:51:37AM +0100, Michael J Gruber wrote: > >>> I assumed that: >>> >>> git commit -a <path> >>> >>> would behave more like the "git add -u <path>" case; add new stuff to >>> the index from <path>, and then commit those changes plus whatever was >>> already in the index. >> >> Yes, you're right. I haven't wrapped my brain completely around those >> mixed cases yet (changes in index + pathspec argument). My aim is that >> >> "git commit <addoptions> <commitoptions> [<pathspec>]" >> >> would be equivalent to (the atomic version of) >> >> "git add <addoptions> [<pathspec>] && git commit <commitoptions>" >> >> and that is difficult because currently, pathspecs are "limiting" for >> commit and "additive" for add without -u. I mean, I don't want to break >> anything, at least not before 1.8.0.. > > I don't think there is any breakage with "-a" (or "-A") there, as you > are adding a new mode of operation that currently doesn't work (e.g., > right now "git commit -a foo" will die). The only thing that would not > work is trying to make: > > git add <path> && git commit > > the same as > > git commit <path> > > But I am not sure that is a good idea anyway. Yes, it is a little > inconsistent with the other forms, but I think it is generally what you > want Very true. I guess that nails our specification. > (which is why the default for commit with paths switched from "-i" > to "-o" long ago). ...before my time (or under my radar). Equivalent options and slightly different defaults should be fine, just as you explained. "-i" is implicit for "add" and "-o" is nonsensical/unnecessary (there is no temp. index for add, but there is reset), so those need not be covered. Michael -- 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