git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Git's inconsistent command line options

From
HWHilco Wijbenga <hilco.wijbenga@gmail.com>
Date
Aug 26, 2015, 01:30 UTC
Message-ID
<CAE1pOi3e8KS9x5yD7CZLESvhXy1oXmQEgUnEFjww7L6JOdZ1Jg@mail.gmail.com>
In-Reply-To
<xmqqa8tfvsr9.fsf@gitster.dls.corp.google.com>
On 25 August 2015 at 16:43, Junio C Hamano <gitster@pobox.com> wrote:
> I do not see a good way to do such a safe transition with command
> words approach, *unless* we are going to introduce new commands,
> i.e. "git list-tag", "git create-tag", etc.

Perhaps we could introduce a more explicit notion (in .git/config) of a Git API version (or, perhaps more accurate, a Git CLI API version)?

The default would be 2 (since we're already at Git 2.x). Git commands could check for this setting and abort/introduce/prevent/change behaviour/functionality as appropriate. During Git 2.x the API 2 would be the default but users could explicitly request 3 in preparation of Git 3.x. (With the knowledge that API 3 would still be [to some extent at least] in flux.) API 2 could start warning about future changes where appropriate. With the introduction of Git 3.x, the default would become API 3 but users could still request API 2. Then for Git 4.x the default would go to 4, with an option to request 3 but 2 would no longer be supported (and all code supporting API 2 could be removed).

I think that from a user's point of view this could work quite well. Obviously, (worst case scenario) Git commands might have to support up to 3 APIs at the same time (previous [2], current [3], and future [4] for Git 3.x) so from a code maintenance POV it would certainly introduce complexity and probably some duplication of code. I'm hopeful it would be limited to CL argument processing but I suspect that when Git code calls other Git code (especially in the Bash based commands) there might be some more complexity there.

Would something like that be feasible?
Previous: Junio C HamanoNext: Junio C Hamano
Message 7 of 25 in “Git's inconsistent command line options”
  1. Graeme GeldenhuysAug 25, 2015
  2. Junio C HamanoAug 25, 2015
  3. Jacob KellerAug 25, 2015
  4. Stefan BellerAug 25, 2015
  5. Jacob KellerAug 25, 2015
  6. Junio C HamanoAug 25, 2015
  7. Hilco WijbengaAug 26, 2015
  8. Junio C HamanoAug 26, 2015
  9. Jacob KellerAug 26, 2015
  10. Junio C HamanoAug 26, 2015
  11. Philip OakleyAug 26, 2015
  12. Jacob KellerAug 26, 2015
  13. Jacob KellerAug 26, 2015
  14. Jacob KellerAug 26, 2015
  15. Andreas SchwabAug 26, 2015
  16. Jacob KellerAug 26, 2015
  17. Duy NguyenAug 31, 2015
  18. Barry WarsawAug 31, 2015
  19. David AguilarSep 1, 2015
  20. Barry WarsawSep 1, 2015
  21. Junio C HamanoSep 1, 2015
  22. Barry WarsawSep 1, 2015
  23. Stefan BellerSep 1, 2015
  24. Michael J GruberSep 9, 2015
  25. Michael J GruberSep 9, 2015

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.