On Thu, 3 Jan 2013, Yang Tse wrote:

>> The splitting of a single header or two surely can't motivate the renaming
>> of 190 *other* files?
>
> True, the splitting doesn't actually motivate the renaming. It would only
> justify the modification of the 190 *other* files.

Yes indeed, but that change would happen anyway on a header split so the
rename is independent of that!

> I accept that it may be a bit disturbing for us to type the new names
> instead of the old ones until we would get used to them. But it is only a
> matter of remembering that _all_ of them are 'curl_' prepended.

I know, and I might've expressed my dislike a little too harsh. I can see
upsides with the rename along the ways you've described I just think of the
downsides to be bigger to not make this rename worth the trouble.

> Additionally we have the multi-allways patch that is going into libcurl
> soonish. Trying to bisect across that patch will make little sense at all.

I think you're over-stating the importance of that patch or perhaps the nature
of its impact. We already support (or should support) the multi interface for
all protocols so most of the stuff the multi-always patch does is removing
some code and fixing code that should already be working anyway. We'll see
that the bugs it will generate are mostly bugs with the multi interface that
exist independently of this patch. The biggest part of my multi-always work
(so far) is tracking down and fixing multi interface bugs, not bugs that is
strictly related to the removal of the internal easy/multi split. (I've done
some of them already as individually cherry-picked commits and there might be
more coming.)

And I'll do multi-always in a single commit so that bisect will certainly work
fine.

> Unless I misinterpreted you I thought libcurl 7.29.0 was going to be a
> no-return point.

This change is certainly somewhat larger than most changes and it does change
internals in a way that will affect the way we work with the code going
forward, but it is not world altering.

> I may be wrong but i believe that it might carry some external functional
> behavior change in 'pingpong' based protocols (ftp, pop3, imap, smtp).

Some, yes. But it needs to be noted that the current behavior is erradic and
error-prone so it really is a bug fix more than anything else. (PHP/CURL had
to implement a work-around recently due to this.)

>> [Tor]
>> I already commented on github on the patch itself,
>
> Could you provide a link to this, or is it some github 'internal' list?

His comment should've been posted to all "collaborators" in the github project
as I understand things! Anyway, here it is:

https://github.com/bagder/curl/commit/5b6e7927c6891d93edc16695ae786dc686274bab#commitcomment-2377730

> Or is history breakage already done no matter what we do? :-((

I would expect it to cause a "disturbance in the force" for the period during
which the rename has been in place, but I'm not a git guru...

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html