[johnthuss]

It seems like this "feature" would greatly constrain the evolution of the API if they have to preserve the shortest version of each option to avoid breaking clients. It would mean "git commit --am" always means "amend" and you can't add another option that starts with "am".

[kevincox]

The docs even spell this out:

> Commands that support the enhanced option parser accepts unique prefix of a long option as if it is fully spelled out, but use this with a caution. For example, git commit --amen behaves as if you typed git commit --amend, but that is true only until a later version of Git introduces another option that shares the same prefix, e.g. git commit --amenity option.

Of course that makes many flag additions technically breaking changes. This could be a surprise because if you accidentally dropped some characters you would have no warning until a Git update breaks it.

[MisterSandman]

That's literally clarified in the Reddit comments. If a new option is added in the future, it will just say `git --am` is ambiguous.

The git man page explicitly says that if you're writing a script of git commands, you should use the full option name, so you won't encounter this ambiguous issue.

So no, it doesn't constraint the evolution of the API.