Hi,

I've re-read all messages in this thread a couple of times, if you
wish to reply to this message, please, don't do it until you've read
it fully ...

In first place. I apologize for not bringing to the list the renaming
change before pushing it to the public repo.

Thanks to all for the pointer to Tor's comment in Github's "notes on
commit 5b6e792" section (and Gisle's prior one), Ive completely missed
it most probably because we never use that workflow to report issues,
and the comment is not e-mailed by Github to the committer, and also
because I nearly never log into Github.

Some points of view or reasons, with which I respectfully disagree,
that have been alleged in order to revert the renaming are, in no
particular order.

Downstream would be conditioning upstream project up to a point where
renaming of upstream internal private files can not be done for once
to achieve a uniform naming schema that would be stable over the time.

Relative to how the renaming has been committed/pushed into git, it
has been mentioned that it breaks the assumption that each post-commit
snapshot is buildable. cURL does not grant even that daily snapshots
are buildable or unbroken.

Relative of what most call 'breakage of history across renames'...

Github problems with file history. Not that problematic given that the
renaming has followed a very specific pattern, for example lets
suppose someone is viewing history of imap.h renamed file at
https://github.com/bagder/curl/commits/master/lib/curl_imap.h and
wishes to see history before renaming took place, it is as 'easy' as
using the same url but removing the 'curl_' part from it
https://github.com/bagder/curl/commits/master/lib/imap.h

Those using local installations of git can follow file's history
crossing renames using --follow option such as for example "git log
--follow lib/curl_imap.h"

If the above mentioned two workarounds are not enough to overcome so
called 'breakage of history across renames' it is not libcurl's fault,
It is simply git's and github's idiosyncrasy, lack of features or
design limitations, you choose. In any case we would be accepting
that, intentional or not, limitations on current version control
system (git) or relative tools (Github, gitk and others) restricts
project development, organization and freedom on what the project can
do and what not.

It has also been mentioned that if the renaming is reverted it will be
easier to cherry-pick bug-fixes from the reversion onwards back into
repos which are not following the master branch (either libcurl
non-public versions or old libcurl versions).

Each libcurl release grants backwards compatibility with itself and
even supports building with tools which are long time ago unsupported
by tool's authors. For libcurl non-public versions (in case there
exists such thing) I may understand the desire to be able to do that
kind of cherry-picking and backporting.

For libcurl public versions there should be no need to be doing that
kind of cherry-pick backporting, we grant backwards compatibility,
although I understand that once in a while there exists the
possibility that some 'lets call it distro' might want to release a
downstream interim release with some specific bug fix.

Can someone, please, point out distros which do this kind of libcurl
interim releases?

The exceptional nature of this public downstream interim releases,
already provides extra work for those that would be doing so. The
inability to automatically cherry-pick bug fixes past 7.29.0 into
pre-7.29.0 versions may even be a good thing for bug fixes which
affect many source files, for those that affect a single file applying
the fix should be fairly easy (although it won't be an automatic
cherry-pick).

Now I'll comment on the potential 'reverting process' itself. Current
situation is that libcurl's git repo at Github has already been
modified with the renaming.

Given that we should not rewrite that repo history. The only sane way
I know of 'undoing' the renaming is pushing a new commit that
'reverts' the renaming but that can simply be pushed into existing
public HEAD. If someone knows how to achieve the reversion in a better
way, please speak up ASAP.

The implications of this new commit will be that "the disturbance in
the force" for those _NOT_ using git will actually disappear.

For those using git and arguing that 'so called history breakage' is
the reason for the reversion, I remind here that with this new commit
there will now exist another extra 'so called history breakage'. Net
effect, two 'so called history breakages'. :-( So for those using git
and Github there would exist two "disturbances in the force".

I've already done the work needed to be done in a local git repo to
revert the changes that have triggered this thread, so we are just a
'git push' command away from the reversion (no merge, a clean commit).

Before pushing this reversion, I'm here asking you all to reconsider
existing situation and if reverting this change is what we actually
want now.

So please, either way express yourselves again. I don't want to goof
it twice in a row.

Thanks,

PS: commit b708a522a1 has already gone public and is ahead of my
reversion work, I'll cope with it.

-- 
-=[Yang]=-
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html