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:
> >
> >>   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.
> >  
> >>   4. Keep README and retire everything else.
> >
> > After you've removed the code, I don't care what you do, but I'd say you
> > should remove the stubs after a long period of time.
> 
> Let's try this in a different way, as I sense there is a
> misunderstanding somewhere about your "wish".
> 
> >> "that" does not refer to "remove them at v2.0 (unconditional)".  It
> >> refers to "If Felipe really wants for the removal for v2.0, I would
> >> respect that".  And I saw you said you did not want to disrupt v2.0.
> >> 
> >> If the options I listed all meant removal at v2.0, then I would
> >> understand your complaints, but that is not the case, so I am not
> >> sure what to make of that.
> >
> > It is a weird choice of semantics then. You said you would "respect" my
> > wish, but your proposals did not "follow" my wish.
> 
> I understand you do not want to disrupt v2.0.  My assumption of that
> "not disrupting v2.0" has been "there still are git-remote-{hg,bzr}
> that work just like what they had in v1.9.x, perhaps with some
> enhancements and regressions you added in the meantime", and I
> understood Peff's comment "If Felipe wants the removal" to mean that
> kind of "disruption", i.e. "there is no git-remote-{hg,bzr} that
> work.", which would be either step 3 or 4.
> 
> But your "After you've removed the code" comment above makes me
> wonder that perhaps your definition of "not disrupting" was
> different from ours (which is not good or bad, just different) and
> you consider that step 3. is "removal but not distupting v2.0"?
> 
> If that is what you want in v2.0, then please say so, and I already
> said I am fine with that.

No, I already said I do not want the code removed from v2.0, that's why
I sent patches that simply added a warning, and I specifically said
those were for 2.0.

However, after seeing this commit:

10e1fee (Revert "Merge branch 'fc/transport-helper-sync-error-fix'")

Which is:

 1) Inaccurate
 2) A lie (*you* broke 2.0, not me)
 3) A disservice to users

I therefore change my wish for you to remove all the remote helpers code
and a replace them with stubs (the patches I originally sent for
post-2.0).

It was a mistake from me to believe you would do the sensible thing for
2.0.

So to make it clear, I now request that you do:

 1) Remove all the code.

    Since my patches were removed from the list, here's an updated patch
    that applies on top of 'master'

    https://github.com/felipec/git/commits/up/remote/remove

 2) Reapply d508e4a (Merge branch 'fc/transport-helper-sync-error-fix')

    Since the code in question is no longer part of v2.0, a "possible
    regression" that you aren't even sure of cannot be the rationale to
    revert this code.

    Your commit 10e1fee (Revert "Merge branch
    'fc/transport-helper-sync-error-fix'") actively hurts the
    out-of-tree tools, so I'll consider a failure to re-revert a hostile
    action.

 3) Update the release notes to mention these tools have been removed

  Additionally, you might want to:

 4) Re-add the following release note:

    * "git push" via transport-helper interface (e.g. remote-hg) has
      been updated to allow forced ref updates in a way similar to the
      natively supported transports

    I don't know why you removed it in the first place. Clearly you pay
    no attention at all to these interfaces.

I expect you to do at the very least 1) and 2).

-- 
Felipe Contreras