From: Stefan Beller <sbeller@google.com>
To: Jacob Keller <jacob.keller@gmail.com>
Cc: Junio C Hamano <gitster@pobox.com>,
Graeme Geldenhuys <graemeg@gmail.com>,
Git Mailing List <git@vger.kernel.org>
Subject: Re: Git's inconsistent command line options
Date: Tue, 25 Aug 2015 15:06:20 -0700 [thread overview]
Message-ID: <CAGZ79kZ6KK0qVtzrxmmsBQqmz-dgamC4f6W0zVTQLcuYi==0fw@mail.gmail.com> (raw)
In-Reply-To: <CA+P7+xrYugueYYrrJV0pduAHCg7CLknE_0QYcU8mO6idntz=VA@mail.gmail.com>
On Tue, Aug 25, 2015 at 2:49 PM, Jacob Keller <jacob.keller@gmail.com> wrote:
> On Tue, Aug 25, 2015 at 8:13 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> On Tue, Aug 25, 2015 at 1:01 AM, Graeme Geldenhuys <graemeg@gmail.com> wrote:
>>>
>>> Even though I have worked with Git since 2009, I still have to
>>> reference the help to remind me of what parameter to use in certain
>>> situation simply because similar tasks differ so much.
>>>
>>> Maybe we could address this in the next major version of Git? Has
>>> anybody else thought about this or started work on this? Or was this
>>> discussed before and declined (link?).
>>
>> http://article.gmane.org/gmane.comp.version-control.git/231478 comes to mind,
>> which has been linked from this entry:
>>
>> Discuss and decide if we want to choose between the "mode word" UI
>> (e.g. "git submodule add") and the "mode option" UI (e.g. "git tag --delete")
>> and standardise on one; if it turns out to be a good idea, devise the migration
>> plan to break the backward-compatibility.
>>
>> in http://git-blame.blogspot.com/p/leftover-bits.html
>
> I would vote for command words, as this is clean and simple.
me too after rereading the arguments in that thread.
> The
> downside is in converting all the old options based commands, git-tag,
> and similar. These commands cannot easily convert because "valid"
> sequences would become invalid with no easy way to deprecate for
> example in the linked gmane above, "git tag delete master" can't be a
> call to delete master as it is currently a call to create a tag
> "delete" at the commit marked by master.
git-tag being a porcelain command (i.e. we do not give a promise to keep
it set to stone) can be changed with a deprecation announcement period.
Say starting with Git 2.6 we would put out warnings for upcoming commands:
$ git tag --delete master
$ echo $?
# 0 # actually works as of today!
$ git tag delete master
# Due to the planned switch to command words, this doesn't work.
# For details see road map at `man git commandwords-roadmaps`
$ echo $?
# 128 maybe ?
$ git tag create delete
And after a while (maybe 3-5 years, once this version is picked up by
debian stable as well as red hat stable)
we can change it, so with Git 3.4(?)
$ git tag --delete master
# --delete is deprecated since 3.4, use `git tag delete` instead
$ echo $?
# 128
$ git tag delete master
# --delete is deprecated since 2.6, use `git tag delete` instead
$ echo $?
# 0 # actually works!
>
> I can't think of an easy way to deprecate the change in behavior over
> time, which means that making a conversion would require some other as
> yet unknown way?
>
> It may be possible to convert other options based commands, such as
> how git-branch and git-checkout do things which seem highly unrelated.
> A good example is how checkout is used to both change branches, as
> well as can create a branch, and can also checkout a file. The "reset"
> command is used to rewind history, as well as potentially reset *all*
> files, but it can't be used to reset a single file, and is completely
> different from revert. Some of these distinctions are ok because it's
> just no good way to make everything easy.
>
> Some of these could be fixed by the command word setup, but as many
> have mentioned an actual migration plan is difficult.
>
> Personally, I don't want to move to the command option "--status"
> format, as I think these aren't really options, and are very much
> sub-subcommands. I think we should try to push more uses of this
> style, and try to determine a possible migration path towards using
> them. Maybe some warts simply aren't worth the effort to fix though.
>
> Other issues are tricker to solve, and are result of git exposing more
> complex functionality and users eventually simply have to learn and
> understand.
>
> Regards,
> Jake
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2015-08-25 22:06 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-25 8:01 Git's inconsistent command line options Graeme Geldenhuys
2015-08-25 15:13 ` Junio C Hamano
2015-08-25 21:49 ` Jacob Keller
2015-08-25 22:06 ` Stefan Beller [this message]
2015-08-25 22:21 ` Jacob Keller
2015-08-25 23:43 ` Junio C Hamano
2015-08-26 1:30 ` Hilco Wijbenga
2015-08-26 17:56 ` Junio C Hamano
2015-08-26 18:10 ` Jacob Keller
2015-08-26 20:48 ` Junio C Hamano
2015-08-26 22:52 ` Philip Oakley
2015-08-26 23:02 ` Jacob Keller
2015-08-26 23:03 ` Jacob Keller
2015-08-26 4:09 ` Jacob Keller
2015-08-26 6:28 ` Andreas Schwab
2015-08-26 6:33 ` Jacob Keller
2015-08-31 10:10 ` Duy Nguyen
2015-08-31 14:25 ` Barry Warsaw
2015-09-01 9:28 ` David Aguilar
2015-09-01 14:19 ` Barry Warsaw
2015-09-01 16:42 ` Junio C Hamano
2015-09-01 17:50 ` Barry Warsaw
2015-09-01 17:56 ` Stefan Beller
2015-09-09 9:42 ` Michael J Gruber
2015-09-09 9:42 ` Michael J Gruber
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAGZ79kZ6KK0qVtzrxmmsBQqmz-dgamC4f6W0zVTQLcuYi==0fw@mail.gmail.com' \
--to=sbeller@google.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=graemeg@gmail.com \
--cc=jacob.keller@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).