On 25 August 2015 at 16:43, Junio C Hamano <gitster@xxxxxxxxx> 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? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html