Hilco Wijbenga <[email protected]> writes:
> On 25 August 2015 at 16:43, Junio C Hamano <[email protected]> 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)?
> ...
> 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?
A bigger issue you need to think about is what to do to scripts
people have. Your approach forces them to update a script to delete
a tag and do something else to say something silly like this:
#!/bin/sh
# My Script
case "$(git config core.apiVersion)" in
"" | 2)
git tag -d "$1"
do something else on "$1" using v2 API
;;
3)
git tag delete "$1"
do something else on "$1" using v3 API
;;
*)
echo >&2 "sorry, I do not know what Git you are using"
exit 1
;;
esac
So, it may be feasible to implement, but I do not think it would be
useful to do so.
Instead, if you really want to invent the multi-version world, you
would rather want to have something more like this:
#!/bin/sh
# My Script
GIT_API_VERSION=2
export GIT_API_VERSION
git tag -d "$1"
do something else on "$1" using v2 API
But notice that I said "if you really want to". I personally think
it is a road to madness.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
