On Tue, Aug 25, 2015 at 4:43 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Stefan Beller <sbeller@xxxxxxxxxx> writes: > >> $ 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 ? > > This is way too aggressive behaviour and is unacceptable as the > first step. The first step of a transition that breaks backward > compatibility should warn loudly about a command line that would > behave differently in the endgame version (either the command line > that will not do anything or do a totally different thing), but > still perform the operation asked for the current version. > > e.g. "git tag delete master" would create a tag named 'delete' > out of 'master', but tell the user that this will instead delete > 'master' in future versions of Git. "git tag create master" > would create a tag named 'create' out of 'master', but tell the > user that this will instead create 'master' out of HEAD in > future versions of Git. > > e.g. "git tag -d foo" would delete a tag named 'foo', but tell > the user that this will have to be spelled 'git tag delete foo' > in the future versions of Git. > > One thing that I am not enthused about the transition plan is that > "git tag delete master" will *never* be an invalid operation during > the transition. When making an operation that used to mean one > thing to mean something else, a good transition plan should be to > > * First warn but do the old thing, and tell users a new way to do > that in the new world order. At the same time, find the new way > that used to be an invalid operation in the old world order, and > implement it. > > * Then stop supporting the old thing and support only the new > thing. > > Then during the transition period, while transitioning to the new > way, people can gradually start using the new way with the new > system, and when they occasionally have to interact with an old > system, the new way will _error out_, because we make sure we find > the new way that "used to be an invalid operation" when planning the > whole transition plan, without causing any harm. And once people > retrain their finger after 2-3 years, nobody will be hurt if we > dropped the old way. > > 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. > > So don't hold your breath. What you two are discussing is way too > uncooked for 2.6 timeframe. > > > Ya, there isn't really a way to make it work, because we can't exactly stop supporting "git tag create master" by turning it into a no-op, because there is no equivalent tag option that would work for now. Since there is no alternative syntax for "create" I think this is the issue. One way might be to use the -- splitter to say, "if you really mean to create a tag named create, use git tag -- create master So we'd do: - step 1 - git tag create master # warn that this will change behavior in the future and they must explicitely pass -- before it - step 2 - break create, but don't add anything new. If user really needs it, they can pass "git tag -- create master" as per above warning, but keep warning on "git tag create master" to say they must be explicit. - step 3 - implement git tag create master to actually perform tag creation I think this might work, as long as "git tag -- create master" is acceptable? then, eventually we can make it so that "git tag" doesn't mean create by default if we ever wanted? How does this sound? By the way, this wouldn't be necessarily done over 2.6 or even over only a single release, I think the time frame would have to be fairly long. The downside is that there is no point where new and old syntax are usable at the same time... but I don't think that will ever be the case. We'd need to way the concern of whether this is actually worth doing to streamline the overall feel at some point in the future or we just live with the warts. Regards, Jake -- 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