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