Re: [RFC PATCH v1 0/1] ls-remote: inconsistency from the order of args and opts

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 14, 2022, 20:42 UTC
Message-ID: <xmqqbl0eaw2e.fsf@gitster.g>
In-Reply-To: <220114.867db2rs0n.gmgdl@evledraar.gmail.com>

Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:

Show 9 quoted lines

> We have multiple commands that are in GNU-fashion loose about whether
> you provide options first before no-option args, or after. E.g. we
> accept both of:
>
>     git push --dry-run <remote> <ref>
>
> And:
>
>     git push <remote> <ref> --dry-run

Yes, but I consider that a bug that we cannot fix due to backward compatibility issues.

That is why my preference is to encourage users to stick to the POSIX way in gltcli, just like we recommend "stuck" form of options its parameter.

Show 7 quoted lines

> But when GNU came around its option parser was generally happy to accept
> options and args in either order. E.g. these both work with GNU
> coreutils, but the latter will fail on FreeBSD and various other
> capital-U UNIX-es:
>
>     touch foo; rm -v foo
>     touch foo; rm foo -v

Yes, among the harm GNU has done on mankind, this is one of the biggest ones. We shouldn't waste our engineering time to support more of them in our tools.

As long as users stick to the recommended "dashed options first and then args, among which revs come first and then pathspecs", they will be fine.