Felipe Contreras <felipe.contreras@xxxxxxxxx> writes: > Junio C Hamano wrote: > >> - The "always warn" does not force update at the point of use, but >> it still does not help them to notice well before they try to use >> it for the first time after update; > > I don't understand this sentence. They will see a big fat warning every > time they run the tool, of course they'll notice. Let me ask one question first, in order to avoid miscommunication, as I really want to get the first step for v2.0-rc4 in a concrete shape tomorrow. Do you think gradual transition worth pursuing or do you think it is a waste of time? I do not think it matters that much, but since you said you do not understand... What I meant was that when they update their Git (perhaps at the beginning of the week), the won't know they will now be running stale code. The warning comes only when they first run it (perhaps at the end of the week) to do some real work with a remote hg repository, which may not be a convenient time to do their sysadmin task. And the next time when they update their Git, they may have already forgotten about the warning. The ideal transition would be to somehow let them notice when they are in sysadmin mode. >> - "Break the build" attempts to help them notice when they try to >> update, not when they need to use the updated one right at this >> moment. > > This cannot be done. Renaming the directory will not "break at the build time" for those who have already did "ln -s" these scripts, of course, but it will "break at the build time" for others (i.e. those who "cp"), no? Again, not very important, as I too consider it optional. If you are shooting for an expedited transition, it is perfectly fine to drop it. > They click that URL, and the are immediately greated with this: > > To enable this, simply add the git-remote-hg script anywhere in your $PATH: > > wget https://raw.github.com/felipec/git-remote-hg/master/git-remote-hg -O ~/bin/git-remote-hg > chmod +x ~/bin/git-remote-hg Perfect. I did check the page when double-checking the URL while writing the README thing, and I did skim the page, but I must have missed it. We could add these two to the warning, then, to discourage people who see "please visit this URL" and say "Yuck, I have no time for that" without actually visiting. >> So to summarize, the following timeline is a full possibility: >> ... >> 2. add warning that is given every time the scripts are run and >> give the same instruction as in README. >> >> 3. (optional) cripple the script to make them always fail after >> showing the same warning as above. > > This is what I want, and I already sent the patches for; the scripts > will be stubs. At this point you would have effectively removed the > code, which what I want. I think explained why the step 3 would not help very much compared to the "there is no script, only README remains" endgame (and that is why it is marked as "optional"). Actually, you reminded me that a very short and easy-to-follow instruction is on the page referred to from README and the warnings, which means that this step would make even less difference compared to the endgame. I don't think I saw you explain why that is not the case and why we do want this step (and I cannot quite tell if you are aiming for more gradual transition that wants this step, or an expedited one that does not). I am fine with either way. In any case, I'd ask another question to avoid wasting time on miscommunication. By "This is what I want", do you mean you want this step 3 also in v2.0, or do you mean you want 2 alone in v2.0 then step 3 some time later? Unless you want 2 and 3 together at v2.0, we do not have to decide the merit of step 3 before v2.0-rc4; if you do want 2 and 3 together for v2.0, then your prompt answer matters a lot. You said your "wish" wasn't "respected" in another message, when I explained that I thought you did not want to disrupt v2.0 by insisting on removing these scripts and that was why I listed options that did not involve removal of the scripts. Are you saying that you wish you want to see them removed or crippled at v2.0? Changing your mind after discussion is perfectly fine, by the way. Thanks. -- 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