Re: Fwd: Possible bug report: `git commit -ammend`
rhys evans rhys.ev...@ft.com writes: I ran `git commit -ammend` on a repo where 1 out of 3 files changed were staged for commit. I would've expected an error to be thrown due to the double typo but instead it committed all 3 files with the message 'mend'. So it looks like it interpreted it as `git commit -a -m 'mend'`. Yes. This is a rather widespread convention (e.g. rm -fr == rm -r -f). Git does a special-case for -amend to avoid confusion: $ git commit -amend error: did you mean `--amend` (with two dashes ?) But it did not special-case the double-typo. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- 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
Re: Fwd: Possible bug report: `git commit -ammend`
On Fri, Nov 15, 2013 at 10:54 PM, Matthieu Moy matthieu@grenoble-inp.fr wrote: rhys evans rhys.ev...@ft.com writes: I ran `git commit -ammend` on a repo where 1 out of 3 files changed were staged for commit. I would've expected an error to be thrown due to the double typo but instead it committed all 3 files with the message 'mend'. So it looks like it interpreted it as `git commit -a -m 'mend'`. Yes. This is a rather widespread convention (e.g. rm -fr == rm -r -f). Git does a special-case for -amend to avoid confusion: $ git commit -amend error: did you mean `--amend` (with two dashes ?) But it did not special-case the double-typo. -m taking a string without a space or '=' increases the risk of this typo. If it does require '=' or ' ' after -m then -ammend is more likely to be rejected. Anybody know why we should support -mabc, besides convenient? -- Duy -- 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
Re: Fwd: Possible bug report: `git commit -ammend`
On Sat, Nov 16, 2013 at 10:28:36AM +0700, Duy Nguyen wrote: Yes. This is a rather widespread convention (e.g. rm -fr == rm -r -f). Git does a special-case for -amend to avoid confusion: $ git commit -amend error: did you mean `--amend` (with two dashes ?) But it did not special-case the double-typo. -m taking a string without a space or '=' increases the risk of this typo. If it does require '=' or ' ' after -m then -ammend is more likely to be rejected. Anybody know why we should support -mabc, besides convenient? For flags with optional arguments, -m abc would not work (we do not know if abc is the argument or the next flag). An example of such a flag is git status -uall. We could disallow it for mandatory options, but that would create an inconsistency in the option parsing. Other than that, I think it is mostly convenience and compatibility with other option-parsing systems. -Peff -- 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
