Re: [PATCH] remote-helpers: point at their upstream repositories

[Felipe Contreras <felipe.contreras@gmail.com>]

Junio C Hamano wrote:
> Felipe Contreras <felipe.contreras@gmail.com> 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?

If by "gradual transition" you mean place the contrib/remote-helpers in
another directory before removing the code, I do think it's a waste of
time, but I don't really care, as long as eventually stubs are put in
place.

> 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.

You can add such change in the release notes. Other than that I don't
see what we could do.

> >>  - "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?

How many people copy the scripts every time they update Git? Not many
I'd gather.

> > 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.

We could. Personally I don't see the point of making the warning any
more annoying. The instructiosn are just one click away, and if they
have no time for that, they can just ignore the warning.

> >> 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.

To me the endgame is that the code is removed, and only stubs remain.
What you do after that is up to you.

> 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?

I meant I want 3. eventually, hopefully for v2.1.

> 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.

You did not specify those were only for v2.0.

No, I don't want them crippled for v2.0. A warning should suffice.

-- 
Felipe Contreras